1. What is ELF? An introduction

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:

• It is much simpler to make shared libraries with ELF. Typically, just compile all the object files with -fPIC, then link with a command like

   gcc -shared -Wl,-soname,libfoo.so.y -o libfoo.so.y.x *.o 
  

  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).
• It makes dynamic loading (ie programs which can load modules at runtime) much simpler. This is used by Perl 5, Python, and Java, among other things (it's a kicker for many kinds of interpreters). Other suggestions for dynamic loading have included super-fast MUDs, where extra code could be compiled and linked into the running executable without having to stop and restart the program.

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.

1.1 What ELF isn't

There are a number of common misconceptions about what ELF will do for your system:

It's not a way to run SVR4 or Solaris programs

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.

It's not intrinsically smaller or faster

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.

It doesn't require that you replace every binary on your system

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 :-)

It's nothing to do with Tolkien.

Or at least, not in this context.

1.2 Why you should convert to ELF

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.

1.3 How to convert to ELF

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 ldconfig and ldd 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?