ELF (Executable and Linking Format) is a binary format originally developed by USL (UNIX System Laboratories) and currently used in Solaris and System V Release 4. Because of its increased flexibility over the older a.out format that Linux previously used, the GCC and C library developers decided last year to move to using ELF as the Linux standard binary format also.
This `increased flexibility' manifests as essentially two benefits to the average applications progammer:
-fPIC, then link with a command like
If that looks complex, you obviously haven't ever read up on the equivalent procedure for a.out shared libraries, which involves compiling the library twice, reserving space for all the data you think that the library is likely to require in future, and registering that address space with a third party (it's described in a document over 20 pages long --- look at ftp://tsx-11.mit.edu/pub/linux/packages/GCC/src/tools-2.17.tar.gz for details).
gcc -shared -Wl,-soname,libfoo.so.y -o libfoo.so.y.x *.o
Against this it must be weighed that ELF is possibly a bit slower.
The figures that get bandied around are between 1% and 5%, though all
the actual tests that have been conducted so far indicate that the
difference is small enough to get lost in the noise of other events
happening at the same time. If you have TeX or a Postscript
viewer/printer, you can read
speed.comp-1.0.tar.gz, which is
available from SunSite somewhere.
The slowdown comes from the fact that ELF library code must be
position independent (this is what the
-fPIC above stands
for) and so a register must be devoted to holding offsets. That's one
less for holding variables in, and the 80x86 has a paucity of
general-purpose registers anyway. Note that the speed difference only
applies to code that is part of shared libraries. For applications or
kernels there is no speed difference between a.out and ELF.
There are a number of common misconceptions about what ELF will do for your system:
Although it's the same binary `container' as SVR4 systems use, that doesn't mean that SVR4 programs suddenly become runnable on Linux. It's analogous to a disk format --- you can keep Linux programs on MSDOS or Minix-format disks, and vice versa, but that doesn't mean that these systems become able to run each others' programs.
It may be possible to run an application for another x86 Unix under
Linux (it depends on the application), but following the instructions
in this HOWTO will not have that effect. Start by looking at the
iBCS kernel module (somewhere on
tsx-11.mit.edu) and see if it
fits your needs.
You may well end up with smaller binaries anyway, though, as you can more easily create shared libraries of common code between many programs. In general, if you use the same compiler options and your binaries come out smaller than they did with a.out, it's more likely to be fluke or a different compiler version. As for `faster', I'd be surprised. Speed increases could turn up if your binaries are smaller, due to less swapping or larger functional areas fitting in cache.
At the end of this procedure you have a system capable of compiling and running both ELF and a.out programs. New programs will by default be compiled in ELF, though this can be overridden with a command-line switch. There is admittedly a memory penalty for running a mixed ELF/a.out system --- if you have both breeds of program running at once you also have two copies of the C library in core, and so on. I've had reports that the speed difference from this is undetectable in normal use on a 6Mb system though (I certainly haven't noticed much in 8Mb), so it's hardly pressing. You lose far more memory every day by running bloated programs like Emacs and static Mosaic/Netscape binaries :-)
Or at least, not in this context.
There are essentially two reasons to upgrade your system to compile and run ELF programs: the first is the increased flexibility in programming referred to above, and the second is that, due to the first, everyone else will (or has already). Current releases of the C library and GCC are compiled only for ELF, and other developers are moving ELFwards too.
Many people are concerned about stability (justifiably so, even if it's not so much fun). ELF on Linux has existed since August 1994 and has been publically available since May or June 1995; the teething troubles are probably out of the way by now. You should allow for the possibility of breaking things --- as you would with any major upgrade --- but the technology that you're upgrading to is no longer bleeding edge. For a system on which any development is done, or on which you want to run other people's precompiled binaries, ELF is pretty much a necessity these days. Plan to switch to it when you upgrade to version 2.0 of the kernel.
When this HOWTO was first written, there was only one way, and it was the way described here. These days there are high-quality upgradable distributions available --- unless you have invested significant time in setting up your machine exactly how you like it, you might find that a backup of all your own data and a reinstall from a recent Red Hat or Debian release is more convenient than messing about with the assorted libraries and compilers described here.
I must stress this. The installation described here is a fairly small
job in itself (it can be completed in well under an hour, excepting
the time taken to download the new software), but there are a
multitude of errors that you can make which will probably leave you
with an unbootable system. If you are not comfortable with upgrading
shared libraries, if the commands
mean nothing to you, or if you're unhappy about building packages from
source code, you should consider the `easy option'. Even if this
description isn't you, think about it anyway --- if you want a `fully
ELF' system, somebody is going to have to recompile all the
binaries on it.
Still with us?