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 currently uses, 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.16.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 the ongoing port of Java to Linux, among other things. 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.

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 is theoretically possible to run applications for other x86 Unices under Linux, 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(n't) 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 be too. Future releases of the C library and GCC will only be compiled for ELF, and other developers are expected to move ELFwards too.

Pleasingly for the purposes of symmetry, there are also two reasons not to convert at this time. The first is that things are still changing, some packages (including the `stable' 1.2 kernel series) require patches to be made before they will compile in ELF, and there may be residual bugs; one could make a strong case for waiting until Linus himself has converted, for example.

The second is that although 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), an error at almost any stage of it will probably leave you with an unbootable system. If you are not comfortable with upgrading shared libraries and the commands ldconfig and ldd mean nothing to you, you may want to obtain or wait for a new Linux distribution in ELF, and backup, reinstall and selectively restore your system using it. Then again (and especially if the system is not mission-critical) you may want to go through it anyway and look on it as a learning experience.

Still with us?