Subject: Re: ELF (Again) (fwd)

From: Melanie Rhianna Lewis <[email-masked]>
Date: Sat, 17 Oct 1998 12:12:16 +0100 (BST)

This didn't appear so I've reposted it!

-- 
=====================================================================
Melanie Rhianna Lewis                      [email-masked]
"An it hurt none, do what thou will"    http://www.defaid.demon.co.uk
         TLBB#2 TGMCC#1 - MZ125, X7 (Under re-construction) 
=====================================================================

---------- Forwarded message ----------
Date: Thu, 15 Oct 1998 10:37:40 +0100 (BST)
From: Melanie Rhianna Lewis <[email-masked]>
To: Arm Linux mailing list <[email-masked]>
Subject: Re: ELF (Again)

On Wed, 14 Oct 1998, Rob Davis wrote:

> Where are things with ELF on a RiscPC these days, and what will it
> mean for your average (non-technical) user?

As you may already know, ELF is the form of executables that most releases
of Linux use.  It is newer than the old aout format.  ArmLinux is a little
behind in this respect.  In ELF libraries are dynamically linked when the
program is run.  Ie the library functions an application needs to run
remain in the libraries and are called from the application.  Where as for
aout the libraries are statically linked. Ie the necessary functions from
the library are included in to the application when the application is
compiled and linked.  This makes it a lot bigger (although slightly faster
to run).

> There was some talk about redoing the binaries etc for ELF, and making
> the libraries work?  

For ELF to work you need a kernel that supports ELF and ELF versions of
the libraries.  In ArmLinux this means glibc...

> Does this mean that it's run things like Netscape straight from the
> setup files, or just that any recompiled program will be smaller? 

It doesn't mean you can run applications written for a different
processor.  So the standard Linux release of Netscape wont work.  It uses
Intel instructions and not ARM ones.  It does mean that all the newer
libraries and applications, which would just be too big in aout format,
can be compiled for ArmLinux.  

The Netwinder which uses a StrongARM processor already has an ELF system
and has the navigator part of Netscape Communicator ported already.
Unfortunately because of Hardware restrictions in the RPC.  Even StrongArm
users can't use the Netwinder apps.  (Although it should work the other
way around).

> Is there going to be an idiots guide to installing it and/or upgading
> to it?

It is my intention to write one once I have done it myself and found all
the pitfalls.  My first job is to find the time to finish building the
cross compiler for my Intel box and then build the ArmLinux stuff.

One point is that ELF will be initially (until someone who's willing puts
lots of hours in) only 32bit addressing.  That means RiscPC upwards...

The debian people are doing a release for the Netwinder which would mean
they could do a release for ArmLinux just by recompiling for the ARM610
(armv3).  I'm not sure of the state of this.

Melanie

-- 
=====================================================================
Melanie Rhianna Lewis                      [email-masked]
"An it hurt none, do what thou will"    http://www.defaid.demon.co.uk
         TLBB#2 TGMCC#1 - MZ125, X7 (Under re-construction) 
=====================================================================

unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Philip Blundell <[email-masked]>
Date: Sun, 18 Oct 1998 16:32:22 +0100

>aout the libraries are statically linked. Ie the necessary functions from

Actually, this isn't quite true.  It's possible to use shared libraries and 
dynamic linking with a.out -- Linux used to do this in libc4 days and NetBSD 
still does for many ports.  However, a.out shared libraries are rather 
gruesome to work with, especially if done the Linux way, and ELF makes this a 
lot easier.

>compiled and linked.  This makes it a lot bigger (although slightly faster

With some binaries this can be quite dramatic actually.  I remember while I
was at college writing a Modula-3 "hello world" program.  The dynamic-linked 
executable was "only" about 1MB, but took something like 10 seconds to start 
because it was pulling in thirty different shared libraries.  The static 
executable was several tens of megabytes but ran almost instantaneously. :-)

The overhead from using PIC for shared libraries is almost certainly 
negligible these days.  The ARM design for PLT is reasonably efficient and I 
think the slowdown there will be more than outweighed by the speed improvement 
you get from using glibc rather than libc4.

>processor.

Indeed.  Though, in theory, because it's far more of a cross-platform standard 
than a.out, you stand a far greater chance of being able to use applications 
written for the same processor but a different operating system.  
(Incidentally, one way to run Netscape for RiscPC owners would be for someone 
to add iBCS support for the ARM and use the NetBSD version; I don't think they 
compile with v4 instructions.)

>lots of hours in) only 32bit addressing.  That means RiscPC upwards...

As it happens, I have simple ELF binaries working on my A5000 now.  The dynamic 
linker is segfaulting which seems to be because the kernel doesn't load it 
properly.  But statically linked things seem OK.  All the code in glibc 
should, I hope, be 26-bit clean and the latest egcs and binutils patches have 
the support needed for old machines.

There are some kernel changes needed for this and I'll try to make patches 
later today.  At the moment I'm using 2.0.35 on the A5000 because 2.1 seems to 
dislike both low-memory systems and ARM3 ones at the moment.

In theory it should be possible to arrange for 26-bit ELF binaries to run on 
all machines so that people with Netwinders can run all the ARM Linux software 
out there. :-)

p.

---

From: Matthew Wilcox <[email-masked]>
Date: Sun, 18 Oct 1998 21:10:50 +0200

> compiled and linked.  This makes it a lot bigger (although slightly faster

Actually, this is not true.  It was true for RiscBSD, and one of the
ways of working round the limitations of our current a.out setup is to
recompile some things statically linked, so it's easy to be confused.

The a.out method of dynamically linking requires libraries to be compiled
at a fixed address.  This has great disadvantages, since it requires
someone to allocate address space, and if your library grows out of the
slot it used to fit in, you have to move it to a totally new address.
In short, it's a maintenance nightmare.  It's particularly bad, since
the same executables run on both 26-bit and 32-bit processors.  So the
libraries are linked in below the 32MB boundary - I believe Russell
said at 20MB for the C library.  This means that anything which requires
large amounts of memory is going to have problems.

> can be compiled for ArmLinux.  

Well, unless Netscape can be persuaded to release a binary compiled for
the ARM.  Which Corel might be able to do, of course.  And don't forget
Mozilla.

-- 
Matthew Wilcox <[email-masked]>
"I decry the current tendency to seek patents on algorithms.  There are
better ways to earn a living than to prevent other people from making use of
one's contributions to computer science."  -- Donald E. Knuth, TAoCP vol 3
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: "Neil A. Carson" <[email-masked]>
Date: Sun, 18 Oct 1998 23:55:19 +0100

> large amounts of memory is going to have problems.

NetBSD (was RiscBSD) uses full PIC with a.out, so it provides for large
applications, position independant shared libraries etc. Things like
gimp, kde, qt, gnome, mozilla, netscape and others all work fine
completely shared up to a maximum of 3gig of address space---no need for
static linking.

-- 
Neil A. Carson

---

From: Melanie Rhianna Lewis <[email-masked]>
Date: Mon, 19 Oct 1998 09:56:35 +0100 (BST)

On Sun, 18 Oct 1998, Philip Blundell wrote lots...

Does anyone object to me writing a few "idiots guide"/"how to" web pages
and putting them on my site.  Critism would be welcome.

Melanie

-- 
=====================================================================
Melanie Rhianna Lewis                      [email-masked]
"An it hurt none, do what thou will"    http://www.defaid.demon.co.uk
   TLBB#2 TGMCC#1 - GS550 (In potentia), X7 (In bits!), MZ 125TS 
=====================================================================

---

From: Melanie Rhianna Lewis <[email-masked]>
Date: Mon, 19 Oct 1998 10:00:12 +0100 (BST)

> the ARM.  Which Corel might be able to do, of course.  And don't forget

Or get ELF working, followed by QT and use the QT Netscape port (browser
only).  This has been done on Netwinder.

Melanie

---

From: Philip Blundell <[email-masked]>
Date: Mon, 19 Oct 1998 11:28:57 +0200

>and putting them on my site.  

No, go ahead.

p.

---

From: Eduard Pfarr <[email-masked]>
Date: Mon, 19 Oct 1998 12:04:56 +0200

> and putting them on my site.  Critism would be welcome.

It would be great to have a few "idiots" guides. Please tell us when they're
ready so we (uhm, I) could test em (because of constructive critism).

 Cheers,
 Eduard.

---

From: "Adam 'WeirdArms' Wiggins" <[email-masked]>
Date: Mon, 19 Oct 1998 21:10:01 +1000 (EST)

> ready so we (uhm, I) could test em (because of constructive critism).

	An "idiots" guide to getting linux on the SA-1100 brutus eval
board would be appreciated if anyone gets the time.

	Cheers Adam

---

From: Alan Cox <[email-masked]>
Date: Mon, 19 Oct 1998 18:29:52 +0100 (BST)

> only).  This has been done on Netwinder.

The official netscape mozilla ports (mo^H^Hlesstif and gtk) should both
work on the ARM too if Qtscape does. Commercial releases will depend on
netscape being shown a market worth having I expect.
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]