Tech Insider					     Technology and Trends


			      USENET Archives

From: Daniel Barlow <daniel...@sjc.ox.ac.uk>
Subject: Linux ELF HOWTO
Date: 1995/07/03
Message-ID: <ELF-HOWTO.1-14320.804811286@cc.gatech.edu>
X-Deja-AN: 105626150
approved: linux-...@news.ornl.gov (Matt Welsh)
sender: gr...@cc.gatech.edu
followup-to: poster
summary: How to install and migrate to the ELF binary file format
organization: Linux HOWTO Project
keywords: Linux, HOWTO, ELF
newsgroups: comp.os.linux.answers,comp.os.linux.development.system,comp.os.linux.setup
nntp-posting-user: gregh

Archive-Name: linux/howto/elf
Last-modified: 2 Jul 95

-----BEGIN PGP SIGNED MESSAGE-----

*** The Linux ELF HOWTO is posted automatically by the Linux
*** HOWTO coordinator, Greg Hankins <gr...@sunsite.unc.edu>.  Please
*** direct any comments or questions about this HOWTO to the author,
*** Daniel Barlow <daniel...@sjc.ox.ac.uk>.

- --- BEGIN Linux ELF HOWTO part 1/1 ---

  The Linux ELF HOWTO
  Daniel Barlow <daniel...@sjc.ox.ac.uk>
  v1.01, June 1995

  This document describes how to migrate your Linux system to compile
  and run programs in the ELF binary format.  It falls into three con-
  ceptual parts: (1) What ELF is, and why/whether you should upgrade,
  (2) How to upgrade to ELF-capability, and (3) what you can do then.

  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:


  o  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





  Now that may look complex, but it's far simpler than the method for
  a.out shared libraries, which involves 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).

  o  It makes dynamic loading (ie programs which can load modules at
     runtime) much simpler.  This is used by Perl 5 and Python, 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 reputed to be possibly a
  bit slower.  The figures that get bandied around are between 2% and
  5%, though as far as I know nobody has done any proper testing.  If
  you do know of any comparative tests, please let me know too.

  The slowdown comes from the fact the ELF library code must be position
  independent (this is what the -fPIC above is 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.  SVR4 uses a different system call convention
        to Linux, and the system calls have different semantics and are
        numbered differently anyway.


     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, Pratchett, Keebler, or general
        mythology" Or at least, not in this context.  'Nuff said.



  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 kernel) 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?


  2.  Installation

  2.1.  Background

  The aim of this conversion is to leave you with a system which can
  build and run both a.out and ELF programs, with each type of program
  being able to find its appropriate breed of shared libraries.  This
  obviously requires a bit more intelligence in the library search
  strategy than the simple `look in /lib, /usr/lib and anywhere else
  that the program was compiled to search' strategy that some other
  systems can get away with.

  The beastie responsible for searching out libraries in linux is
  /lib/ld.so.  The compiler and linker do not encode absolute library
  pathnames into the programs they output; instead they put the library
  name and the absolute path to ld.so in, and leave ld.so to match the
  library name to the appropriate place at runtime.  This has one very
  important effect --- it means that the libraries that a program uses
  can be moved to other directories without recompiling the program,
  provided that ld.so is told to search the new directory.  This is
  essential for the directory swapping operation that follows.

  The corollary of the above, of course, is that any attempt to delete
  or move ld.so will cause every dynamically linked program on the
  system to stop working.  This is generally regarded as a Bad Thing.

  For ELF binaries, an alternate dynamic loader is provided.  This is
   /lib/ld-linux.so.1, and does exactly the same thing as ld.so, but for
  ELF programs.  ld-linux.so.1 uses the same support files and programs
  (ldd, ldconfig, and /etc/ld.so.conf) as the a.out loader ld.so does.

  The basic plan, then, is that ELF development things (compilers,
  include files and libraries) go into /usr/{bin,lib,include} where your
  a.out ones currently are, and the a.out things will be moved into
  /usr/i486-linuxaout/{bin, lib, include}.  /etc/ld.so.conf lists all
  the places on the system where libraries are expected to be found, and
  ldconfig is intelligent enough to distinguish between ELF and a.out
  variants.  There are a couple of exceptions to the library placement,
  though; see the Caveats section below.


  2.2.  Before you start --- Notes and Caveats


  o  You will need to be running a post-1.1.52 kernel with ELF binary
     format support.  Note that kernel versions 1.3.0 to 1.3.2 inclusive
     had an ELF-related bug.  If you're running the development 1.3
     kernel series, make sure you stay current!  1.3.3 is fine, as is
     1.2.10 (the latest stable kernel at time of writing).

  o  You are recommended to prepare or acquire a linux boot/root disk,
     such as a Slackware rescue disk.  You probably won't need it, but
     if you do and you don't have one, you'll kick yourself.

  o  Extra care is needed if you have /usr or /usr/lib on a separate
     partition from /.  You will need to check the libraries that your
     programs in /bin and /sbin use, and put those libraries somewhere
     on the root partition, say in /lib-aout.  I'll come back to this at
     the appropriate spot.

  o  If you have been following the ELF development, you may have ELF
     libraries in /lib/elf (usually libc.so.4 and co).  Applications
     that you built using these should be rebuilt, then the directory
     removed.  There is no need for a /lib/elf directory!  It was used
     for a time during ELF development, but how it ended up as a
     standard directory in Slackware installs, who knows?

  o  Some old programs don't use ld.so, so any libraries that they
     depend on cannot be moved.  There may or may not be a problem here.
     Use ldd to determine which these libraries are.  If the program
     depends only on libc.so.4 and/or libm.so.4, there is no problem, as
     these libraries continue to reside in /lib.  If it depends on X in
     any way, shape, or form, you're also safe: to be old enough not to
     use ld.so it would have to have been compiled with a pretty old
     version of the X libraries, and both the major version number and
     directory placement of the X libraries has changed since then.

     If you do have a clash between an a.out library that cannot be
     moved and an ELF library with the same major version that wants to
     install over the top of it, you'll have to put the ELF library
     somewhere else and add the other directory to /etc/ld.so.conf.

     If your system is old enough that you still have shared libraries
     with dates in the filenames then you're obviously a Linux God(tm)
     and should be advising me on the appropriate course of action at
     this point :-)  Answers to the address in the title of this HOWTO.

  o  Most Linux installations these days have converged on the `FSSTND'
     standard file system, but doubtless there are still installed
     systems that haven't.  If you see references to /sbin/something and
     you don't have a /sbin directory, you'll probably find the program
     referred to in /bin or /etc/.


  2.3.  You will need ...

  The following packages are available from
  <ftp://tsx-11.mit.edu/pub/linux/packages/GCC/> and
  <ftp://sunsite.unc.edu/pub/Linux/GCC/>.  Both sites are widely
  mirrored; please take the time to look up your nearest mirror site and
  use that instead of the master sites where possible.  It's faster for
  both you and everyone else.

  These packages (either the listed version or a later one) are
  required.  Also download and read through the release notes for each
  of them: these are the files named release.packagename.  This applies
  especially if you get newer versions than are listed here, as
  procedures may have changed.


  o  ld.so-1.7.3.tar.gz --- the new dynamic linker

  o  libc-5.0.9.bin.tar.gz --- the ELF shared images for the C library
     and its friends (m (maths), termcap, gdbm, and so on), plus the
     corresponding static libraries and the include files needed to
     compile programs with them.

  o  gcc-2.7.0.bin.tar.gz --- the ELF C compiler.  Also includes an
     a.out C compiler which understands the new directory layout.

  o  binutils-2.5.2l.17.bin.tar.gz --- the GNU binary utilities patched
     for Linux.  These are programs such as gas, ld, strings and so on,
     most of which are required to make the C compiler go.



  2.4.  Rearranging your filesystem

  Sooo...  Note that in all that follows, when I say `remove' I
  naturally mean `backup then remove' :-).  Also, these instructions
  directly apply only to people who haven't yet messed with ELF ---
  those who have are expected to have the necessary nous to adapt as
  appropriate.  Let's go!


  1. If you have separate / and /usr partitions, some caution is
     required here.  You must check each program that is run at startup
     before /usr is mounted, or run in other situations where /usr is
     unavailable, and put all the libraries required by it in /lib-aout.

     This is actually less tedious than it sounds.  Simply run



       $ ldd /sbin/* /bin/* /etc/* >/tmp/list.txt





  and then look through /tmp/list.txt , ignoring all the errors from
  non-executable files, and noting which libraries appear.  These are
  the libraries which you will need on the root partition.  Keep this
  list.

  2. Make the new directories that you will move a.out things to


       ______________________________________________________________________
       mkdir -p /usr/i486-linuxaout/bin
       mkdir -p /usr/i486-linuxaout/include
       mkdir -p /usr/i486-linuxaout/lib
       mkdir /lib-aout
       ______________________________________________________________________





  3. Untar the dynamic linker package ld.so-1.7.3 in the directory you
     usually put source code, then read through the
     ld.so-1.7.3/instldso.sh script just unpacked.  If you have a really
     standard system, run it by doing sh instldso.sh, but if you have
     anything at all unusual then do the install by hand instead.
     `Anything at all unusual' includes

  o  using zsh as a shell (some versions of zsh define $VERSION, which
     seems to confuse instldso.sh)

  o  having symlinks from /lib/elf to /lib (which you shouldn't need,
     but you may have valid reasons for if you have been following the
     ELF development)


     Edit /etc/ld.so.conf to add the new directory
     /usr/i486-linuxaout/lib (and /lib-aout if you're going to need
     one).  Then rerun /sbin/ldconfig -v to check that it is picking up
     the new directories.

  4. Find all your a.out libraries other than libc and libm and move
     them from /usr/*/lib to /usr/i486-linuxaout/lib or /lib-aout as
     appropriate.  Don't move, delete or do anything with /lib/ld.so!
     For people with only the one partition, the following series of
     commands are pretty well what you need to do.



       ______________________________________________________________________
       cd /lib
       mv *.o *.a *.sa /usr/i486-linuxaout/lib
       mv [ lib*.so* except for libc.so* and libm.so* ] /usr/i486-linuxaout/lib
       cd /usr/lib
       mv *.o *.a *.so* *.sa /usr/i486-linuxaout/lib
       cd /usr/X11R6/lib
       mv *.o *.a *.so* *.sa /usr/i486-linuxaout/lib
       cd /usr/local/lib
       mv *.o *.a *.so* *.sa /usr/i486-linuxaout/lib
       ______________________________________________________________________





  Do not pass this stage until you have removed all libraries and object
  (*.o) files from each of the above directories, except for libc.so*
  and libm.so* in /lib, which you need to keep so that aged programs
  continue to work, and ld.so in /lib, which you still need for anything
  to work.

  5. Remove the directory /usr/lib/ldscripts if it's there.

  6. Remove any copies of ld and as (except for ld86 and as86) that you
     can find in /usr/bin.

  7. Some versions of GNU tar appear to have problems dealing with
     symbolically linked files.  Before installing the libc images you
     might want to go through /usr/include and remove some parts.

     This is icky.  Many packages (such as ncurses) are installed into
     /usr/include by distribution maintainers and are not supplied with
     the C library.  Backup the /usr/include tree, use tar tzf to see
     what's in the file before untarring it, and delete the directories
     that it actually fills.  Then untar the libc-5.0.9.bin.tar.gz
     package from root.

  8. You have now installed everything you need to run ELF executables.
     Medical experts recommend that VDU workers take regular breaks away
     from the screen; this would be an opportune moment.

  9. Now we come to installing some ELF programs.  Install the binutils
     package.  tar -xvzf binutils-2.5.2l.17.bin.tar.gz -C / is one
     perfectly good way to do this.

  10.
     Backup and remove everything in /usr/lib/gcc-lib/{i486-linux,
     i486-linuxelf, i486-linuxaout}/ Then install the gcc package, again
     by untarring from root.

   Done!  Simple tests that you can try are









  ______________________________________________________________________
  $ gcc -v
  Reading specs from /usr/lib/gcc-lib/i486-linux/2.7.0/specs
  gcc version 2.7.0
  $ gcc -v -b i486-linuxaout
  Reading specs from /usr/lib/gcc-lib/i486-linuxaout/2.7.0/specs
  gcc version 2.7.0
  $ ld -V
  ld version cygnus/linux-2.5.2l.14 (with BFD cygnus/linux-2.5.2l.11)
    Supported emulations:
     elf_i386
     i386linux
     i386coff
  ______________________________________________________________________




  followed of course by the traditional ``Hello, world'' program.  Try
  it with gcc and with gcc -b i486-linuxaout to check that both the
  a.out and ELF compilers are set up corectly.


  2.5.  Common errors

  I'm soliciting reports of people's problems for this section.  Your
  anonymity will be preserved if you so request :-)


      no such file or directory: /usr/bin/gcc
        that the ELF dynamic loader /lib/ld-linux.so.1 is not installed,
        or is unreadable for some reason.  You should have installed it
        at around step 3 of the previous section.


      not a ZMAGIC file, skipping
        from ldconfig.  You have an old version of the ld.so package, so
        get a recent one.  Again, see step 3 of the previous section.


      bad address
        on attempting to run anything ELF.  You're using kernel 1.3.x,
        where x<3.  Upgrade to 1.3.3 or downgrade to 1.2.something



  3.  Building programs in ELF

  3.1.  Ordinary programs

  To build a program in ELF, use gcc as always.  To build in a.out, use
  gcc -b i486-linuxaout .



       ______________________________________________________________________
       $ cat >hello.c
       main() { printf("hello, world\n"); }
       ^D
       $ gcc -o hello hello.c
       $ file hello
       hello: ELF 32-bit LSB executable i386 (386 and up) Version 1
       $ ./hello
       hello, world
       ______________________________________________________________________

  This is perhaps an appropriate time to answer the question ``if a.out
  compilers default to producing a program called a.out, what name does
  an ELF compiler give its output?''.  Still a.out, is the answer.
  Boring boring boring ...  :-)


  3.2.  Building libraries

  To build libfoo.so as a shared library, the basic steps look like
  this:



       ______________________________________________________________________
       $ gcc -fPIC -c *.c
       $ gcc -shared -Wl,-soname,libfoo.so.1 -o libfoo.so.1.0 *.o
       $ ln -s libfoo.so.1.0 libfoo.so.1
       $ ln -s libfoo.so.1 libfoo.so
       $ export LD_LIBRARY_PATH=`pwd`:$LD_LIBRARY_PATH
       ______________________________________________________________________




  This will generate a shared library called libfoo.so.1.0, and the
  appropriate links for ld (libfoo.so) and the dynamic linker
  (libfoo.so.1) to find it.  To test, we add the current directory to
  LD_LIBRARY_PATH.

  When you're happpy that the library works, you'll have to move it to,
  say, /usr/local/lib, and recreate the appropriate links.  Note that
  the libfoo.so link should point to libfoo.so.1, so it doesn't need
  updating on every minor version number change.  The link from
  libfoo.so.1 to libfoo.so.1.0 is kept up to date by ldconfig, which on
  most systems is run as part of the boot process.



       ______________________________________________________________________
       $ su
       # cp libfoo.so.1.0 /usr/local/lib
       # /sbin/ldconfig
       # ( cd /usr/local/lib ; ln -s libfoo.so.1 libfoo.so )
       ______________________________________________________________________






  3.3.  Programs with dynamic loading

  These are covered extensively in H J Lu's ELF programming document,
  and the dlopen(3) manual page, which can be found in the ld.so
  package.  Here's a nice simple example though: link it with -ldl











  ______________________________________________________________________
  #include <dlfcn.h>
  #include <stdio.h>

  main()
  {
    void *libc;
    void (*printf_call)();

    if(libc=dlopen("/lib/libc.so.5",RTLD_LAZY))
    {
      printf_call=dlsym(libc,"printf");
      (*printf_call)("hello, world\n");
    }

  }
  ______________________________________________________________________





  3.4.  Debugging

  Your existing copy of gdb will most likely work unchanged with ELF
  programs.  The new version in the GCC directory on tsx-11 is reported
  to be better at debugging programs that use dynamic loading and to
  understand ELF core dumps.

  At the time of writing, a patch to the kernel is necessary before ELF
  programs will generate core dumps anyway, so it's perhaps a little
  academic.


  4.  Patches and binaries

  At this point in the proceedings, you can, if you like, stop.  You
  have installed everything necessary to compile and run ELF programs.

  You may wish to rebuild some programs in ELF, either for purposes of
  `neatness' or to minimise memory usage.  For most end-user
  applications, this is pretty simple; some packages however do assume
  too much about the systems they run on, and may fail due to one or
  more of:

  o  Different underscore conventions in the assembler: in an a.out
     executable, external labels get _ prefixed to them; in an ELF
     executable, they don't.  This makes no difference until you start
     integrating hand-written assembler: all the labels of the form _foo
     must be translated to foo, or (if you want to be portable about it)
     to EXTERNAL(foo) where EXTERNAL is some macro which returns either
     its argument (if __ELF__ is defined) or _ concatenated with its
     argument if not.

  o  Differences in libc 5 from libc 4.  The interface to the locale
     support has changed, for one.

  o  The application or build process depends on knowledge of the binary
     format used --- emacs, for example, dumps its memory image to disk
     in executable format, so obviously needs to know what format your
     executables are in.

  o  The application consists of or includes shared libraries (X11 is
     the obvious example).  These will obviously need changes to
     accomodate the different method of shared library creation in ELF.

  Anyway, here are two lists: the first is of programs that needed
  changing for ELF where the changes have been made (ie that you will
  need new versions of to compile as ELF), and the second is of programs
  that still need third-party patches of some kind.


  4.1.  Upgrade:


  o  Dosemu.  Modulo the three or four cuurrent dosemu development trees
     (don't ask, just join the linux-msdos mailing list), dosemu runs
     with ELF.  You'll need to monkey with the Makefile.  Current
     versions of dosemu are available from
     <ftp://tsx-11.mit.edu/pub/linux/ALPHA/dosemu/>

  o  Emacs.  Emacs has a rather odd build procedure that involves
     running a minimal version of itself, loading in all the useful bits
     as lisp, then dumping its memory image back to disk as an
     executable file.  Emacs 19.29 detects whether you are compiling as
     ELF and Does The Right Thing automatically.  (For XEmacs, see the
     second list)

  o  perl 5.001.  Perl 5.001 plus the ``official unofficial'' patches a-
     e will compile unchanged on an ELF system, complete with dynamic
     loading.  The patches are available from ftp.metronet.com or
     ftp.wpi.edu

  o  The cal program in util-linux 2.2 doesn't work.  Upgrade to version
     2.4 <ftp://tsx-11.mit.edu/pub/linux/packages/utils> or later.

  o  XFree86.  As the build for this includes a bunch of shared
     libraries, it shouldn't be too surprising that it requires changing
     so that it builds ELF libraries.  A complete binary distribution is
     available from  <ftp://ftp.beckman.uiuc.edu/pub/linux/X11/> or
     <ftp://ftp.mcc.ac.uk/pub/linux/ALPHA/XFree86-3.1.1-ELF-3/>.



  4.2.  Patch


  o  e2fsutils.  The Utilities for the Second Extended File System need
     a patch from
     <http://sable.ox.ac.uk/~jo95004/patches/e2fsutils.diff> to compile
     correctly as a shared library.  Remy Card says ``This is the ELF
     patch which will probably be included in the next release of e2fsck
     and co''

  o  file.  This works anyway, but can be improved:
     <http://sable.ox.ac.uk/~jo95004/patches/file.diff> adds support for
     identifying stripped and mixed-endian ELF binaries.

  o  The Kernel.  There are two issues here: (a) will it run ELF
     binaries (to which the answer is `yes, if were asked and replied
     affirmatively to the question ``Kernel support for ELF binaries''
     when you did make config'), and (b) can it be compiled in ELF.  The
     answer to (b) is generally `no', so you'll need to patch the
     Makefile slightly to use the a.out compiler.  Just change the CC
     and LD definitions to be







  ______________________________________________________________________
  LD      =ld -m i386linux
  CC      =gcc -b i486-linuxaout -D__KERNEL__ -I$(TOPDIR)/include
  ______________________________________________________________________





  An alternative solution to (b) is to apply H J Lu's patch which allows
  compiling the kernel in ELF (and also adds the ability to do ELF core
  dumps).  This is expected to be integrated into the development 1.3
  series fairly soon, but requires someone to hack around with the psup-
  date program for namelist support in ps and associated utilities.

  o  SVGATextMode requires a single simple adjustment.  Cut out the diff
     below and apply it, or else make the patch by hand.



       ______________________________________________________________________
       --- SVGATextMode-0.7.orig/XFREE/os-support/assyntax.h   Sun Feb 26 18:58:15 1995
       +++ SVGATextMode-0.7/XFREE/os-support/assyntax.h        Thu Mar 30 07:52:03 1995
       @@ -211,7 +211,7 @@
        #endif /* ACK_ASSEMBLER */


       -#if (defined(SYSV) || defined(SVR4)) && !defined(ACK_ASSEMBLER)
       +#if (defined (__ELF__) || defined(SYSV) || defined(SVR4)) && !defined(ACK_ASSEMBLER)
        #define GLNAME(a)       a
        #else
        #define GLNAME(a)       CONCAT(_,a)
       ______________________________________________________________________






  o  XEmacs.  Try  <http://sable.ox.ac.uk/~jo95004/patches/xemacs.diff>
     for XEmacs 19.11.


  5.  Further information



  o  The linux-gcc mailing list is really the best place to see what's
     happening, usually without even posting to it.  Remember, it's not
     Usenet, so keep the questions down unless you're actually
     developing.  For instructions on joining the mailing list, mail a
     message containing the word help to majo...@vger.rutgers.edu

  o  See also Bobby Shmit's ELF upgrade experience
     <http://www.intac.com/~cully/elf.html> web page.

  o  The GCC-FAQ <ftp://sunsite.unc.edu/pub/Linux/docs/faqs/GCC-
     FAQ.html> contains much general development information and some
     more technical ELF details.

  o  There's also documentation for the file format on tsx-11
     <ftp://tsx-11.mit.edu/pub/linux/packages/GCC/ELF.doc.tar.gz>.  This
     is probably of most use to people who want to understand, debug or
     rewrite programs that deal directly with binary objects.


  o  H J Lu's document ELF: From The Programmer's Perspective
     <ftp://tsx-11.mit.edu/pub/linux/packages/GCC/elf.latex.tar.gz>
     contains much useful and more detailed information on programming
     with ELF.  If you aren't LaTeX-capable, it is also available in
     Postscript. <ftp://tsx-11.mit.edu/pub/linux/packages/GCC/elf.ps.gz>

  o  There is a manual page for dlopen(3) supplied with the ld.so
     package.


  6.  Copyright

  This document is copyright (C) 1995 Daniel Barlow
  <daniel...@sjc.ox.ac.uk> It may be reproduced and distributed in
  whole or in part, in any medium physical or electronic, as long as
  this copyright notice is retained on all copies. Commercial
  redistribution is allowed and encouraged; however, the author would
  like to be notified of any such distributions.

  All translations, derivative works, or aggregate works incorporating
  any Linux HOWTO documents must be covered under this copyright notice.
  That is, you may not produce a derivative work from a HOWTO and impose
  additional restrictions on its distribution. Exceptions to these rules
  may be granted under certain conditions; please contact the Linux
  HOWTO coordinator at the address given below.

  In short, we wish to promote dissemination of this information through
  as many channels as possible. However, we do wish to retain copyright
  on the HOWTO documents, and would like to be notified of any plans to
  redistribute the HOWTOs.

  If you have questions, please contact Greg Hankins, the Linux HOWTO
  coordinator, at gr...@sunsite.unc.edu via email, or at +1 404 853
  9989.

- --- END Linux ELF HOWTO part 1/1 ---

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: finger gr...@cc.gatech.edu for public key

iQCVAwUBL/hyB3tNTo2suu5NAQFnGAP/ZszkQ2MYbCo2DP7y82nSWr3DTvq9jBx6
vcI7+oTDtDFCwwUnocNc7To+4UbCAA1TPWlLiLFfvcEezDxUhaLNVvnPSj+8B93F
ZR6GxnAfbNP6oAfhVS/f4sV9R0GXF+GI4a+dnRghCpjWStPIFKfEV1aC11geCjxs
RJmCEkxBcKw=
=W6Jf
-----END PGP SIGNATURE-----

From: Daniel Barlow <daniel...@sjc.ox.ac.uk>
Subject: Linux ELF HOWTO
Date: 1995/08/10
Message-ID: <ELF-HOWTO.1-13380.808094964@cc.gatech.edu>
X-Deja-AN: 107911067
approved: linux-...@news.ornl.gov (Matt Welsh)
sender: gr...@cc.gatech.edu
followup-to: poster
summary: How to install and migrate to the ELF binary file format
organization: Linux HOWTO Project
keywords: Linux, HOWTO, ELF
newsgroups: comp.os.linux.answers,comp.os.linux.development.system,comp.os.linux.setup
nntp-posting-user: gregh

Archive-Name: linux/howto/elf
Last-modified: 6 Aug 95

-----BEGIN PGP SIGNED MESSAGE-----

*** The Linux ELF HOWTO is posted automatically by the Linux
*** HOWTO coordinator, Greg Hankins <gr...@sunsite.unc.edu>.  Please
*** direct any comments or questions about this HOWTO to the author,
*** Daniel Barlow <daniel...@sjc.ox.ac.uk>.

- --- BEGIN Linux ELF HOWTO part 1/1 ---

  The Linux ELF HOWTO
  Daniel Barlow <daniel...@sjc.ox.ac.uk>
  v1.03, August 1995

  This document describes how to migrate your Linux system to compile
  and run programs in the ELF binary format.  It falls into three con-
  ceptual parts: (1) What ELF is, and why/whether you should upgrade,
  (2) How to upgrade to ELF-capability, and (3) what you can do then.

  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:


  o  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





  Now that may look complex, but it's far simpler than the method for
  a.out shared libraries, which involves 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).

  o  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 reputed to be possibly a
  bit slower.  The figures that get bandied around are between 2% and
  5%, though as far as I know nobody has done any proper testing.  If
  you do know of any comparative tests, please let me know too.

  The slowdown comes from the fact the ELF library code must be position
  independent (this is what the -fPIC above is 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, Pratchett, Keebler, or general
        mythology" Or at least, not in this context.  'Nuff said.



  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?


  2.  Installation

  2.1.  Background

  The aim of this conversion is to leave you with a system which can
  build and run both a.out and ELF programs, with each type of program
  being able to find its appropriate breed of shared libraries.  This
  obviously requires a bit more intelligence in the library search
  strategy than the simple `look in /lib, /usr/lib and anywhere else
  that the program was compiled to search' strategy that some other
  systems can get away with.

  The beastie responsible for searching out libraries in linux is
  /lib/ld.so.  The compiler and linker do not encode absolute library
  pathnames into the programs they output; instead they put the library
  name and the absolute path to ld.so in, and leave ld.so to match the
  library name to the appropriate place at runtime.  This has one very
  important effect --- it means that the libraries that a program uses
  can be moved to other directories without recompiling the program,
  provided that ld.so is told to search the new directory.  This is
  essential for the directory swapping operation that follows.

  The corollary of the above, of course, is that any attempt to delete
  or move ld.so will cause every dynamically linked program on the
  system to stop working.  This is generally regarded as a Bad Thing.

  For ELF binaries, an alternate dynamic loader is provided.  This is
   /lib/ld-linux.so.1, and does exactly the same thing as ld.so, but for
  ELF programs.  ld-linux.so.1 uses the same support files and programs
  (ldd, ldconfig, and /etc/ld.so.conf) as the a.out loader ld.so does.

  The basic plan, then, is that ELF development things (compilers,
  include files and libraries) go into /usr/{bin,lib,include} where your
  a.out ones currently are, and the a.out things will be moved into
  /usr/i486-linuxaout/{bin, lib, include}.  /etc/ld.so.conf lists all
  the places on the system where libraries are expected to be found, and
  ldconfig is intelligent enough to distinguish between ELF and a.out
  variants.  There are a couple of exceptions to the library placement,
  though; see the Caveats section below.


  2.2.  Before you start --- Notes and Caveats


  o  You will need to be running a post-1.1.52 kernel with ELF binary
     format support.  Note that kernel versions 1.3.0 to 1.3.2 inclusive
     had an ELF-related bug.  If you're running the development 1.3
     kernel series, make sure you stay current!  1.3.3 is fine, as is
     1.2.10 (the latest stable kernel at time of writing).

  o  You are recommended to prepare or acquire a linux boot/root disk,
     such as a Slackware rescue disk.  You probably won't need it, but
     if you do and you don't have one, you'll kick yourself.  In a
     similar `prevention is better than cure' vein, statically linked
     copies of mv, ln, and maybe other file manipulation commands
     (though in fact I think you can do everything else you actually
     need to with shell builtins) may help you out of any awkward
     situations you could end up in.

  o  Extra care is needed if you have /usr or /usr/lib on a separate
     partition from /.  You will need to check the libraries that your
     programs in /bin and /sbin use, and put those libraries somewhere
     on the root partition, say in /lib-aout.  I'll come back to this at
     the appropriate spot.

  o  If you have been following the ELF development, you may have ELF
     libraries in /lib/elf (usually libc.so.4 and co).  Applications
     that you built using these should be rebuilt, then the directory
     removed.  There is no need for a /lib/elf directory!  It was used
     for a time during ELF development, but how it ended up as a
     standard directory in Slackware installs, who knows?

  o  Some old programs don't use ld.so, so any libraries that they
     depend on cannot be moved.  There may or may not be a problem here.
     Use ldd to determine which these libraries are.  If the program
     depends only on libc.so.4 and/or libm.so.4, there is no problem, as
     these libraries continue to reside in /lib.  If it depends on X in
     any way, shape, or form, you're also safe: to be old enough not to
     use ld.so it would have to have been compiled with a pretty old
     version of the X libraries, and both the major version number and
     directory placement of the X libraries has changed since then.

     If you do have a clash between an a.out library that cannot be
     moved and an ELF library with the same major version that wants to
     install over the top of it, you'll have to put the ELF library
     somewhere else and add the other directory to /etc/ld.so.conf.

     If your system is old enough that you still have shared libraries
     with dates in the filenames then you're obviously a Linux God(tm)
     and should be advising me on the appropriate course of action at
     this point :-)  Answers to the address in the title of this HOWTO.

  o  Most Linux installations these days have converged on the `FSSTND'
     standard file system, but doubtless there are still installed
     systems that haven't.  If you see references to /sbin/something and
     you don't have a /sbin directory, you'll probably find the program
     referred to in /bin or /etc/.


  2.3.  You will need ...

  The following packages are available from
  <ftp://tsx-11.mit.edu/pub/linux/packages/GCC/> and
  <ftp://sunsite.unc.edu/pub/Linux/GCC/>.  Both sites are widely
  mirrored; please take the time to look up your nearest mirror site and
  use that instead of the master sites where possible.  It's faster for
  both you and everyone else.

  These packages (either the listed version or a later one) are
  required.  Also download and read through the release notes for each
  of them: these are the files named release.packagename.  This applies
  especially if you get newer versions than are listed here, as
  procedures may have changed.


  o  ld.so-1.7.3.tar.gz --- the new dynamic linker

  o  libc-5.0.9.bin.tar.gz --- the ELF shared images for the C library
     and its friends (m (maths), termcap, gdbm, and so on), plus the
     corresponding static libraries and the include files needed to
     compile programs with them.

  o  gcc-2.7.0.bin.tar.gz --- the ELF C compiler.  Also includes an
     a.out C compiler which understands the new directory layout.

  o  binutils-2.5.2l.17.bin.tar.gz --- the GNU binary utilities patched
     for Linux.  These are programs such as gas, ld, strings and so on,
     most of which are required to make the C compiler go.  Note that
     you can also use binutils-2.5.2l.20.bin.tar.gz, if it's arrived in
     your part of the world.


  2.4.  Rearranging your filesystem

  Sooo...  Note that in all that follows, when I say `remove' I
  naturally mean `backup then remove' :-).  Also, these instructions
  directly apply only to people who haven't yet messed with ELF ---
  those who have are expected to have the necessary nous to adapt as
  appropriate.  Let's go!


  1. If you have separate / and /usr partitions, some caution is
     required here.  You must check each program that is run at startup
     before /usr is mounted, or run in other situations where /usr is
     unavailable, and put all the libraries required by it in /lib-aout.

     This is actually less tedious than it sounds.  Simply run



       $ ldd /sbin/* /bin/* /etc/* >/tmp/list.txt





  and then look through /tmp/list.txt , ignoring all the errors from
  non-executable files, and noting which libraries appear.  These are
  the libraries which you will need on the root partition.  Keep this
  list.

  2. Make the new directories that you will move a.out things to


       ______________________________________________________________________
       mkdir -p /usr/i486-linuxaout/bin
       mkdir -p /usr/i486-linuxaout/include
       mkdir -p /usr/i486-linuxaout/lib
       mkdir /lib-aout
       ______________________________________________________________________





  3. Untar the dynamic linker package ld.so-1.7.3 in the directory you
     usually put source code, then read through the
     ld.so-1.7.3/instldso.sh script just unpacked.  If you have a really
     standard system, run it by doing sh instldso.sh, but if you have
     anything at all unusual then do the install by hand instead.
     `Anything at all unusual' includes

  o  using zsh as a shell (some versions of zsh define $VERSION, which
     seems to confuse instldso.sh)

  o  having symlinks from /lib/elf to /lib (which you shouldn't need,
     but you may have valid reasons for if you have been following the
     ELF development)
     Edit /etc/ld.so.conf to add the new directory
     /usr/i486-linuxaout/lib (and /lib-aout if you're going to need
     one).  Then rerun /sbin/ldconfig -v to check that it is picking up
     the new directories.

  4. Move all your a.out libraries in /usr/*/lib to
     /usr/i486-linuxaout/lib.  If /usr is not on the root partition,
     refer now to the list you made of libraries that are needed in
     single-user mode, and move them from /lib to /lib-aout.  After
     doing that, or if you didn't need to do that, move all remaining
     libraries in /lib to /usr/i486-linuxaout/lib.  Don't move, delete
     or do anything with /lib/ld.so!

     For people with only the one partition, the following series of
     commands are pretty well what you need to do.



       ______________________________________________________________________
       cd /lib
       mv *.o *.a *.sa /usr/i486-linuxaout/lib
       mv libfoo.so* libbar.so* libmumble.so*  /usr/i486-linuxaout/lib
       cd /usr/lib
       mv *.o *.a *.so* *.sa /usr/i486-linuxaout/lib
       cd /usr/X11R6/lib
       mv *.o *.a *.so* *.sa /usr/i486-linuxaout/lib
       cd /usr/local/lib
       mv *.o *.a *.so* *.sa /usr/i486-linuxaout/lib
       ______________________________________________________________________






  If you actually typed in the third line of that without reading it
  first, you'll observe that it didn't do anything.  What you should be
  attempting to do there is move all files matching *.so* except for
  libc.so*, libm.so* and libdl.so* to /usr/i486-linuxaout/lib.  I can't
  advise more specifically than that as I don't know what libraries you
  have in /lib

  Do not pass this stage until you have removed all libraries and object
  (*.o) files from each of the above directories, except for libc.so*,
  libm.so* and libdl.so* in /lib, which you need to keep so that aged
  programs continue to work, and ld.so in /lib, which you still need for
  anything to work.  Now run ldconfig again.


  5. Remove the directory /usr/lib/ldscripts if it's there.

  6. Remove any copies of ld and as (except for ld86 and as86) that you
     can find in /usr/bin.

  7. Some versions of GNU tar appear to have problems dealing with
     symbolically linked files.  Before installing the libc images you
     might want to go through /usr/include and remove some parts.

     This is icky.  Many packages (such as ncurses) are installed into
     /usr/include by distribution maintainers and are not supplied with
     the C library.  Backup the /usr/include tree, use tar tzf to see
     what's in the file before untarring it, and delete the directories
     that it actually fills.  Then untar the libc-5.0.9.bin.tar.gz
     package from root.


  8. Install the binutils package.  tar -xvzf
     binutils-2.6.2.l17.bin.tar.gz -C /  is one perfectly good way to do
     this.

  9. You have now installed everything you need to run ELF executables.
     Medical experts recommend that VDU workers take regular breaks away
     from the screen; this would be an opportune moment.  Don't forget
     what you were doing, though; depending on the version of gcc you
     were previously using, you may have left yourself unable to compile
     programs in a.out until you unpack the new gcc.

  10.
     Backup and remove everything in /usr/lib/gcc-lib/{i486-linux,
     i486-linuxelf, i486-linuxaout}/ Then install the gcc package, again
     by untarring from root.

  11.
     Some programs (notably various X programs) use /lib/cpp, which
     under Linux is generally a link to /usr/lib/gcc-
     lib/i486-linux/version/cpp.  As the preceding step wiped out
     whatever version of cpp it was pointing to, you'll need to recreate
     the link:



       $ cd /lib
       $ ln -s /usr/lib/gcc-lib/i486-linux/2.7.0/cpp .





   Done!  Simple tests that you can try are



       ______________________________________________________________________
       $ gcc -v
       Reading specs from /usr/lib/gcc-lib/i486-linux/2.7.0/specs
       gcc version 2.7.0
       $ gcc -v -b i486-linuxaout
       Reading specs from /usr/lib/gcc-lib/i486-linuxaout/2.7.0/specs
       gcc version 2.7.0
       $ ld -V
       ld version cygnus/linux-2.5.2l.14 (with BFD cygnus/linux-2.5.2l.11)
         Supported emulations:
          elf_i386
          i386linux
          i386coff
       ______________________________________________________________________




  followed of course by the traditional ``Hello, world'' program.  Try
  it with gcc and with gcc -b i486-linuxaout to check that both the
  a.out and ELF compilers are set up corectly.


  2.5.  Common errors

  I'm soliciting reports of people's problems for this section.  Your
  anonymity will be preserved if you so request :-)



      no such file or directory: /usr/bin/gcc
        that the ELF dynamic loader /lib/ld-linux.so.1 is not installed,
        or is unreadable for some reason.  You should have installed it
        at around step 3 of the previous section.


      not a ZMAGIC file, skipping
        from ldconfig.  You have an old version of the ld.so package, so
        get a recent one.  Again, see step 3 of the previous section.


      bad address
        on attempting to run anything ELF.  You're using kernel 1.3.x,
        where x<3.  Upgrade to 1.3.3 or downgrade to 1.2.something


      _setutent: Can't open utmp file
        You didn't read the libc release notes.  In accordance with
        version 1.2 of the FSSTND, utmp and wtmp have moved again, and
        should now be located in /var/run and /var/log respectively.
        Recommended practice is to add symlinks from their old locations
        so that your older programs will also find them.  Don't forget
        to check your startup scripts (/etc/bcheckrc, for example) to
        make sure you're not deleting things you shouldn't at startup.


      gcc: installation problem, cannot exec something: No such file or
        directory
        when attempting to do a.out compilations (something is usually
        one of cpp or cc1).  Either it's right, or alternatively you
        typed



          $ gcc -b -i486-linuxaout




     when you should have typed



          $ gcc -b i486-linuxaout




     Note that the `i486' does not start with a dash.



  3.  Building programs in ELF

  3.1.  Ordinary programs

  To build a program in ELF, use gcc as always.  To build in a.out, use
  gcc -b i486-linuxaout .








  ______________________________________________________________________
  $ cat >hello.c
  main() { printf("hello, world\n"); }
  ^D
  $ gcc -o hello hello.c
  $ file hello
  hello: ELF 32-bit LSB executable i386 (386 and up) Version 1
  $ ./hello
  hello, world
  ______________________________________________________________________




  This is perhaps an appropriate time to answer the question ``if a.out
  compilers default to producing a program called a.out, what name does
  an ELF compiler give its output?''.  Still a.out, is the answer.
  Boring boring boring ...  :-)


  3.2.  Building libraries

  To build libfoo.so as a shared library, the basic steps look like
  this:



       ______________________________________________________________________
       $ gcc -fPIC -c *.c
       $ gcc -shared -Wl,-soname,libfoo.so.1 -o libfoo.so.1.0 *.o
       $ ln -s libfoo.so.1.0 libfoo.so.1
       $ ln -s libfoo.so.1 libfoo.so
       $ export LD_LIBRARY_PATH=`pwd`:$LD_LIBRARY_PATH
       ______________________________________________________________________




  This will generate a shared library called libfoo.so.1.0, and the
  appropriate links for ld (libfoo.so) and the dynamic linker
  (libfoo.so.1) to find it.  To test, we add the current directory to
  LD_LIBRARY_PATH.

  When you're happpy that the library works, you'll have to move it to,
  say, /usr/local/lib, and recreate the appropriate links.  Note that
  the libfoo.so link should point to libfoo.so.1, so it doesn't need
  updating on every minor version number change.  The link from
  libfoo.so.1 to libfoo.so.1.0 is kept up to date by ldconfig, which on
  most systems is run as part of the boot process.



       ______________________________________________________________________
       $ su
       # cp libfoo.so.1.0 /usr/local/lib
       # /sbin/ldconfig
       # ( cd /usr/local/lib ; ln -s libfoo.so.1 libfoo.so )
       ______________________________________________________________________








  3.3.  Programs with dynamic loading

  These are covered extensively in H J Lu's ELF programming document,
  and the dlopen(3) manual page, which can be found in the ld.so
  package.  Here's a nice simple example though: link it with -ldl



       ______________________________________________________________________
       #include <dlfcn.h>
       #include <stdio.h>

       main()
       {
         void *libc;
         void (*printf_call)();

         if(libc=dlopen("/lib/libc.so.5",RTLD_LAZY))
         {
           printf_call=dlsym(libc,"printf");
           (*printf_call)("hello, world\n");
         }

       }
       ______________________________________________________________________





  3.4.  Debugging

  Your existing copy of gdb will most likely work unchanged with ELF
  programs.  The new version in the GCC directory on tsx-11 is reported
  to be better at debugging programs that use dynamic loading and to
  understand ELF core dumps.

  At the time of writing, a patch to the kernel is necessary before ELF
  programs will generate core dumps anyway, so it's perhaps a little
  academic.


  4.  Patches and binaries

  At this point in the proceedings, you can, if you like, stop.  You
  have installed everything necessary to compile and run ELF programs.

  You may wish to rebuild some programs in ELF, either for purposes of
  `neatness' or to minimise memory usage.  For most end-user
  applications, this is pretty simple; some packages however do assume
  too much about the systems they run on, and may fail due to one or
  more of:

  o  Different underscore conventions in the assembler: in an a.out
     executable, external labels get _ prefixed to them; in an ELF
     executable, they don't.  This makes no difference until you start
     integrating hand-written assembler: all the labels of the form _foo
     must be translated to foo, or (if you want to be portable about it)
     to EXTERNAL(foo) where EXTERNAL is some macro which returns either
     its argument (if __ELF__ is defined) or _ concatenated with its
     argument if not.

  o  Differences in libc 5 from libc 4.  The interface to the locale
     support has changed, for one.


  o  The application or build process depends on knowledge of the binary
     format used --- emacs, for example, dumps its memory image to disk
     in executable format, so obviously needs to know what format your
     executables are in.

  o  The application consists of or includes shared libraries (X11 is
     the obvious example).  These will obviously need changes to
     accomodate the different method of shared library creation in ELF.

  Anyway, here are two lists: the first is of programs that needed
  changing for ELF where the changes have been made (ie that you will
  need new versions of to compile as ELF), and the second is of programs
  that still need third-party patches of some kind.


  4.1.  Upgrade:


  o  Dosemu.  Modulo the three or four cuurrent dosemu development trees
     (don't ask, just join the linux-msdos mailing list), dosemu runs
     with ELF.  You'll need to monkey with the Makefile.  Current
     versions of dosemu are available from
     <ftp://tsx-11.mit.edu/pub/linux/ALPHA/dosemu/>

  o  Emacs.  Emacs has a rather odd build procedure that involves
     running a minimal version of itself, loading in all the useful bits
     as lisp, then dumping its memory image back to disk as an
     executable file.  (FSF) Emacs 19.29 and XEmacs 19.12 (formerly
     Lucid Emacs) can both detect whether you are compiling as ELF and
     Do The Right Thing automatically.

  o  MAKEDEV.  In some incarnations, this utility removes existing
     entries for devices before recreating them.  This is Bad News if it
     happens to touch /dev/zero, as said device is necessary to the
     operation of all ELF programs.  See the util-linux package(q.v.)
     for a fixed version.

  o  perl 5.001.  Perl 5.001 plus the ``official unofficial'' patches a-
     e will compile unchanged on an ELF system, complete with dynamic
     loading.  The patches are available from ftp.metronet.com or
     ftp.wpi.edu

  o  The cal program in util-linux 2.2 doesn't work.  Upgrade to version
     2.4 <ftp://tsx-11.mit.edu/pub/linux/packages/utils> or later.

  o  XFree86.  XFree86 3.1.2 comes in both a.out and ELF formats.  ftp
     to ftp.xfree86.org, read the `too many users' message that you are
     almost guaranteed to get, and pick the closest mirror site network-
     wise to you.

     I confess to not having actually tried this yet.  At time of
     writing, it's only been out for one day ;-)


  4.2.  Patch


  o  e2fsutils.  The Utilities for the Second Extended File System need
     a patch from
     <ftp://ftp.ibp.fr/pub/linux/ELF/patches/e2fsprogs-0.5b.elf.diff.gz>
     to compile correctly as a shared library.  Remy Card says ``This is
     the ELF patch which will probably be included in the next release
     of e2fsck and co''

  o  file.  This works anyway, but can be improved:
     <http://sable.ox.ac.uk/~jo95004/patches/file.diff> adds support for
     identifying stripped and mixed-endian ELF binaries.

  o  The Kernel.  As from at least 1.3.8, the development 1.3 series
     have a make config option to build using ELF tools.  If you are
     using the 1.2 series, you have two options:


     1. Patch the Makefile slightly to use the a.out compiler.  Just
        change the CC and LD definitions to be



          ___________________________________________________________________
          LD      =ld -m i386linux
          CC      =gcc -b i486-linuxaout -D__KERNEL__ -I$(TOPDIR)/include
          ___________________________________________________________________





     Alternatively,

     2. Apply H J Lu's patch which allows compiling the kernel in ELF
        (and also adds the ability to do ELF core dumps).


     Let me reiterate that neither of these is necessary for the 1.3
     series.

  o  ps (procps-0.97) The psupdate program needs a patch to work if you
     have compiled the kernel as ELF.  It's available in
     <linux.nrao.edu:/pub/people/juphoff/procps>, both as a patch to
     vanilla 0.97 and as an entire tar-file.  A new version of procps is
     expected to be released soon with this patch in place, so if you
     can find procps 0.98 by the time you read this, this patch will
     probably be obsolete.

  o  SVGATextMode requires a single simple adjustment.  Cut out the diff
     below and apply it, or else make the patch by hand.



       ______________________________________________________________________
       --- SVGATextMode-0.7.orig/XFREE/os-support/assyntax.h   Sun Feb 26 18:58:15 1995
       +++ SVGATextMode-0.7/XFREE/os-support/assyntax.h        Thu Mar 30 07:52:03 1995
       @@ -211,7 +211,7 @@
        #endif /* ACK_ASSEMBLER */


       -#if (defined(SYSV) || defined(SVR4)) && !defined(ACK_ASSEMBLER)
       +#if (defined (__ELF__) || defined(SYSV) || defined(SVR4)) && !defined(ACK_ASSEMBLER)
        #define GLNAME(a)       a
        #else
        #define GLNAME(a)       CONCAT(_,a)
       ______________________________________________________________________






  5.  Further information



  o  The linux-gcc mailing list is really the best place to see what's
     happening, usually without even posting to it.  Remember, it's not
     Usenet, so keep the questions down unless you're actually
     developing.  For instructions on joining the mailing list, mail a
     message containing the word help to majo...@vger.rutgers.edu

  o  There's a certain amount of information about what the linux-gcc
     list is doing at my ELF web page
     <http://sable.ox.ac.uk/~jo95004/elf.html>, when I remember to
     update it.  Archives of the list itself are at
     <http://homer.ncm.com/>.

  o  See also Bobby Shmit's ELF upgrade experience
     <http://www.intac.com/~cully/elf.html> web page.

  o  The GCC-FAQ <ftp://sunsite.unc.edu/pub/Linux/docs/faqs/GCC-
     FAQ.html> contains much general development information and some
     more technical ELF details.

  o  There's also documentation for the file format on tsx-11
     <ftp://tsx-11.mit.edu/pub/linux/packages/GCC/ELF.doc.tar.gz>.  This
     is probably of most use to people who want to understand, debug or
     rewrite programs that deal directly with binary objects.

  o  H J Lu's document ELF: From The Programmer's Perspective
     <ftp://tsx-11.mit.edu/pub/linux/packages/GCC/elf.latex.tar.gz>
     contains much useful and more detailed information on programming
     with ELF.  If you aren't LaTeX-capable, it is also available as
     PostScript.

  o  There is a manual page for dlopen(3) supplied with the ld.so
     package.


  6.  Legalese

  All trademarks used in this document are acknowledged as being owned
  by their respective owners.  (Spot the teeth-gritting irony there...)


  The right of Daniel Barlow to be identified as the author of this work
  has been asserted in accordance with sections 77 and 78 of the
  Copyright Designs and Patents Act 1988.  (Proof by assertion

  This document is copyright (C) 1995 Daniel Barlow
  <daniel...@sjc.ox.ac.uk> It may be reproduced and distributed in
  whole or in part, in any medium physical or electronic, as long as
  this copyright notice is retained on all copies. Commercial
  redistribution is allowed and encouraged; however, the author would
  like to be notified of any such distributions.

  All translations, derivative works, or aggregate works incorporating
  any Linux HOWTO documents must be covered under this copyright notice.
  That is, you may not produce a derivative work from a HOWTO and impose
  additional restrictions on its distribution. Exceptions to these rules
  may be granted under certain conditions; please contact the Linux
  HOWTO coordinator at the address given below.

  In short, we wish to promote dissemination of this information through
  as many channels as possible. However, we do wish to retain copyright
  on the HOWTO documents, and would like to be notified of any plans to
  redistribute the HOWTOs.

  If you have questions, please contact Greg Hankins, the Linux HOWTO
  coordinator, at gr...@sunsite.unc.edu via email, or at +1 404 853
  9989.

- --- END Linux ELF HOWTO part 1/1 ---

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: finger gr...@cc.gatech.edu for public key

iQCVAwUBMCqM5ntNTo2suu5NAQFZ0QP+LGAOTqiCac6ZJ7kgVVC2rc6UijKrdtZc
K8VST2Jc9l/sDWB2SXTcjCz2IxCgOfjvFYkvmGx7EBrhR/2H+/vIIt1m9wAJfCm3
tA9swIH/AEVdx12SvLTWfp6hFo0LeLnvkkORZBm+rjow6NqCSflxzc40WsEcWQrx
bKwChHVH9vo=
=FTwT
-----END PGP SIGNATURE-----

From: Daniel Barlow <daniel...@sjc.ox.ac.uk>
Subject: Linux ELF HOWTO
Date: 1995/09/12
Message-ID: <ELF-HOWTO.1-16643.810946321@cc.gatech.edu>
X-Deja-AN: 109987117
approved: linux-...@news.ornl.gov (Matt Welsh)
sender: gr...@cc.gatech.edu
followup-to: poster
summary: How to install and migrate to the ELF binary file format
organization: Linux HOWTO Project
keywords: Linux, HOWTO, ELF
newsgroups: comp.os.linux.answers,comp.os.linux.development.system,comp.os.linux.setup
nntp-posting-user: gregh

Archive-Name: linux/howto/elf
Last-modified: 12 Sep 95

-----BEGIN PGP SIGNED MESSAGE-----

*** The Linux ELF HOWTO is posted automatically by the Linux
*** HOWTO coordinator, Greg Hankins <gr...@sunsite.unc.edu>.  Please
*** direct any comments or questions about this HOWTO to the author,
*** Daniel Barlow <daniel...@sjc.ox.ac.uk>.

- --- BEGIN Linux ELF HOWTO part 1/1 ---

  The Linux ELF HOWTO
  Daniel Barlow <daniel...@sjc.ox.ac.uk>
  v1.03, August 1995

  This document describes how to migrate your Linux system to compile
  and run programs in the ELF binary format.  It falls into three con-
  ceptual parts: (1) What ELF is, and why/whether you should upgrade,
  (2) How to upgrade to ELF-capability, and (3) what you can do then.

  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:


  o  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





  Now that may look complex, but it's far simpler than the method for
  a.out shared libraries, which involves 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).

  o  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 reputed to be possibly a
  bit slower.  The figures that get bandied around are between 2% and
  5%, though as far as I know nobody has done any proper testing.  If
  you do know of any comparative tests, please let me know too.

  The slowdown comes from the fact the ELF library code must be position
  independent (this is what the -fPIC above is 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, Pratchett, Keebler, or general
        mythology" Or at least, not in this context.  'Nuff said.



  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?


  2.  Installation

  2.1.  Background

  The aim of this conversion is to leave you with a system which can
  build and run both a.out and ELF programs, with each type of program
  being able to find its appropriate breed of shared libraries.  This
  obviously requires a bit more intelligence in the library search
  strategy than the simple `look in /lib, /usr/lib and anywhere else
  that the program was compiled to search' strategy that some other
  systems can get away with.

  The beastie responsible for searching out libraries in linux is
  /lib/ld.so.  The compiler and linker do not encode absolute library
  pathnames into the programs they output; instead they put the library
  name and the absolute path to ld.so in, and leave ld.so to match the
  library name to the appropriate place at runtime.  This has one very
  important effect --- it means that the libraries that a program uses
  can be moved to other directories without recompiling the program,
  provided that ld.so is told to search the new directory.  This is
  essential for the directory swapping operation that follows.

  The corollary of the above, of course, is that any attempt to delete
  or move ld.so will cause every dynamically linked program on the
  system to stop working.  This is generally regarded as a Bad Thing.

  For ELF binaries, an alternate dynamic loader is provided.  This is
   /lib/ld-linux.so.1, and does exactly the same thing as ld.so, but for
  ELF programs.  ld-linux.so.1 uses the same support files and programs
  (ldd, ldconfig, and /etc/ld.so.conf) as the a.out loader ld.so does.

  The basic plan, then, is that ELF development things (compilers,
  include files and libraries) go into /usr/{bin,lib,include} where your
  a.out ones currently are, and the a.out things will be moved into
  /usr/i486-linuxaout/{bin, lib, include}.  /etc/ld.so.conf lists all
  the places on the system where libraries are expected to be found, and
  ldconfig is intelligent enough to distinguish between ELF and a.out
  variants.  There are a couple of exceptions to the library placement,
  though; see the Caveats section below.


  2.2.  Before you start --- Notes and Caveats


  o  You will need to be running a post-1.1.52 kernel with ELF binary
     format support.  Note that kernel versions 1.3.0 to 1.3.2 inclusive
     had an ELF-related bug.  If you're running the development 1.3
     kernel series, make sure you stay current!  1.3.3 is fine, as is
     1.2.10 (the latest stable kernel at time of writing).

  o  You are recommended to prepare or acquire a linux boot/root disk,
     such as a Slackware rescue disk.  You probably won't need it, but
     if you do and you don't have one, you'll kick yourself.  In a
     similar `prevention is better than cure' vein, statically linked
     copies of mv, ln, and maybe other file manipulation commands
     (though in fact I think you can do everything else you actually
     need to with shell builtins) may help you out of any awkward
     situations you could end up in.

  o  Extra care is needed if you have /usr or /usr/lib on a separate
     partition from /.  You will need to check the libraries that your
     programs in /bin and /sbin use, and put those libraries somewhere
     on the root partition, say in /lib-aout.  I'll come back to this at
     the appropriate spot.

  o  If you have been following the ELF development, you may have ELF
     libraries in /lib/elf (usually libc.so.4 and co).  Applications
     that you built using these should be rebuilt, then the directory
     removed.  There is no need for a /lib/elf directory!  It was used
     for a time during ELF development, but how it ended up as a
     standard directory in Slackware installs, who knows?

  o  Some old programs don't use ld.so, so any libraries that they
     depend on cannot be moved.  There may or may not be a problem here.
     Use ldd to determine which these libraries are.  If the program
     depends only on libc.so.4 and/or libm.so.4, there is no problem, as
     these libraries continue to reside in /lib.  If it depends on X in
     any way, shape, or form, you're also safe: to be old enough not to
     use ld.so it would have to have been compiled with a pretty old
     version of the X libraries, and both the major version number and
     directory placement of the X libraries has changed since then.

     If you do have a clash between an a.out library that cannot be
     moved and an ELF library with the same major version that wants to
     install over the top of it, you'll have to put the ELF library
     somewhere else and add the other directory to /etc/ld.so.conf.

     If your system is old enough that you still have shared libraries
     with dates in the filenames then you're obviously a Linux God(tm)
     and should be advising me on the appropriate course of action at
     this point :-)  Answers to the address in the title of this HOWTO.

  o  Most Linux installations these days have converged on the `FSSTND'
     standard file system, but doubtless there are still installed
     systems that haven't.  If you see references to /sbin/something and
     you don't have a /sbin directory, you'll probably find the program
     referred to in /bin or /etc/.


  2.3.  You will need ...

  The following packages are available from
  <ftp://tsx-11.mit.edu/pub/linux/packages/GCC/> and
  <ftp://sunsite.unc.edu/pub/Linux/GCC/>.  Both sites are widely
  mirrored; please take the time to look up your nearest mirror site and
  use that instead of the master sites where possible.  It's faster for
  both you and everyone else.

  These packages (either the listed version or a later one) are
  required.  Also download and read through the release notes for each
  of them: these are the files named release.packagename.  This applies
  especially if you get newer versions than are listed here, as
  procedures may have changed.


  o  ld.so-1.7.3.tar.gz --- the new dynamic linker

  o  libc-5.0.9.bin.tar.gz --- the ELF shared images for the C library
     and its friends (m (maths), termcap, gdbm, and so on), plus the
     corresponding static libraries and the include files needed to
     compile programs with them.

  o  gcc-2.7.0.bin.tar.gz --- the ELF C compiler.  Also includes an
     a.out C compiler which understands the new directory layout.

  o  binutils-2.5.2l.17.bin.tar.gz --- the GNU binary utilities patched
     for Linux.  These are programs such as gas, ld, strings and so on,
     most of which are required to make the C compiler go.  Note that
     you can also use binutils-2.5.2l.20.bin.tar.gz, if it's arrived in
     your part of the world.


  2.4.  Rearranging your filesystem

  Sooo...  Note that in all that follows, when I say `remove' I
  naturally mean `backup then remove' :-).  Also, these instructions
  directly apply only to people who haven't yet messed with ELF ---
  those who have are expected to have the necessary nous to adapt as
  appropriate.  Let's go!


  1. If you have separate / and /usr partitions, some caution is
     required here.  You must check each program that is run at startup
     before /usr is mounted, or run in other situations where /usr is
     unavailable, and put all the libraries required by it in /lib-aout.

     This is actually less tedious than it sounds.  Simply run



       $ ldd /sbin/* /bin/* /etc/* >/tmp/list.txt





  and then look through /tmp/list.txt , ignoring all the errors from
  non-executable files, and noting which libraries appear.  These are
  the libraries which you will need on the root partition.  Keep this
  list.

  2. Make the new directories that you will move a.out things to


       ______________________________________________________________________
       mkdir -p /usr/i486-linuxaout/bin
       mkdir -p /usr/i486-linuxaout/include
       mkdir -p /usr/i486-linuxaout/lib
       mkdir /lib-aout
       ______________________________________________________________________





  3. Untar the dynamic linker package ld.so-1.7.3 in the directory you
     usually put source code, then read through the
     ld.so-1.7.3/instldso.sh script just unpacked.  If you have a really
     standard system, run it by doing sh instldso.sh, but if you have
     anything at all unusual then do the install by hand instead.
     `Anything at all unusual' includes

  o  using zsh as a shell (some versions of zsh define $VERSION, which
     seems to confuse instldso.sh)

  o  having symlinks from /lib/elf to /lib (which you shouldn't need,
     but you may have valid reasons for if you have been following the
     ELF development)
     Edit /etc/ld.so.conf to add the new directory
     /usr/i486-linuxaout/lib (and /lib-aout if you're going to need
     one).  Then rerun /sbin/ldconfig -v to check that it is picking up
     the new directories.

  4. Move all your a.out libraries in /usr/*/lib to
     /usr/i486-linuxaout/lib.  If /usr is not on the root partition,
     refer now to the list you made of libraries that are needed in
     single-user mode, and move them from /lib to /lib-aout.  After
     doing that, or if you didn't need to do that, move all remaining
     libraries in /lib to /usr/i486-linuxaout/lib.  Don't move, delete
     or do anything with /lib/ld.so!

     For people with only the one partition, the following series of
     commands are pretty well what you need to do.



       ______________________________________________________________________
       cd /lib
       mv *.o *.a *.sa /usr/i486-linuxaout/lib
       mv libfoo.so* libbar.so* libmumble.so*  /usr/i486-linuxaout/lib
       cd /usr/lib
       mv *.o *.a *.so* *.sa /usr/i486-linuxaout/lib
       cd /usr/X11R6/lib
       mv *.o *.a *.so* *.sa /usr/i486-linuxaout/lib
       cd /usr/local/lib
       mv *.o *.a *.so* *.sa /usr/i486-linuxaout/lib
       ______________________________________________________________________






  If you actually typed in the third line of that without reading it
  first, you'll observe that it didn't do anything.  What you should be
  attempting to do there is move all files matching *.so* except for
  libc.so*, libm.so* and libdl.so* to /usr/i486-linuxaout/lib.  I can't
  advise more specifically than that as I don't know what libraries you
  have in /lib

  Do not pass this stage until you have removed all libraries and object
  (*.o) files from each of the above directories, except for libc.so*,
  libm.so* and libdl.so* in /lib, which you need to keep so that aged
  programs continue to work, and ld.so in /lib, which you still need for
  anything to work.  Now run ldconfig again.


  5. Remove the directory /usr/lib/ldscripts if it's there.

  6. Remove any copies of ld and as (except for ld86 and as86) that you
     can find in /usr/bin.

  7. Some versions of GNU tar appear to have problems dealing with
     symbolically linked files.  Before installing the libc images you
     might want to go through /usr/include and remove some parts.

     This is icky.  Many packages (such as ncurses) are installed into
     /usr/include by distribution maintainers and are not supplied with
     the C library.  Backup the /usr/include tree, use tar tzf to see
     what's in the file before untarring it, and delete the directories
     that it actually fills.  Then untar the libc-5.0.9.bin.tar.gz
     package from root.


  8. Install the binutils package.  tar -xvzf
     binutils-2.6.2.l17.bin.tar.gz -C /  is one perfectly good way to do
     this.

  9. You have now installed everything you need to run ELF executables.
     Medical experts recommend that VDU workers take regular breaks away
     from the screen; this would be an opportune moment.  Don't forget
     what you were doing, though; depending on the version of gcc you
     were previously using, you may have left yourself unable to compile
     programs in a.out until you unpack the new gcc.

  10.
     Backup and remove everything in /usr/lib/gcc-lib/{i486-linux,
     i486-linuxelf, i486-linuxaout}/ Then install the gcc package, again
     by untarring from root.

  11.
     Some programs (notably various X programs) use /lib/cpp, which
     under Linux is generally a link to /usr/lib/gcc-
     lib/i486-linux/version/cpp.  As the preceding step wiped out
     whatever version of cpp it was pointing to, you'll need to recreate
     the link:



       $ cd /lib
       $ ln -s /usr/lib/gcc-lib/i486-linux/2.7.0/cpp .





   Done!  Simple tests that you can try are



       ______________________________________________________________________
       $ gcc -v
       Reading specs from /usr/lib/gcc-lib/i486-linux/2.7.0/specs
       gcc version 2.7.0
       $ gcc -v -b i486-linuxaout
       Reading specs from /usr/lib/gcc-lib/i486-linuxaout/2.7.0/specs
       gcc version 2.7.0
       $ ld -V
       ld version cygnus/linux-2.5.2l.14 (with BFD cygnus/linux-2.5.2l.11)
         Supported emulations:
          elf_i386
          i386linux
          i386coff
       ______________________________________________________________________




  followed of course by the traditional ``Hello, world'' program.  Try
  it with gcc and with gcc -b i486-linuxaout to check that both the
  a.out and ELF compilers are set up corectly.


  2.5.  Common errors

  I'm soliciting reports of people's problems for this section.  Your
  anonymity will be preserved if you so request :-)



      no such file or directory: /usr/bin/gcc
        that the ELF dynamic loader /lib/ld-linux.so.1 is not installed,
        or is unreadable for some reason.  You should have installed it
        at around step 3 of the previous section.


      not a ZMAGIC file, skipping
        from ldconfig.  You have an old version of the ld.so package, so
        get a recent one.  Again, see step 3 of the previous section.


      bad address
        on attempting to run anything ELF.  You're using kernel 1.3.x,
        where x<3.  Upgrade to 1.3.3 or downgrade to 1.2.something


      _setutent: Can't open utmp file
        You didn't read the libc release notes.  In accordance with
        version 1.2 of the FSSTND, utmp and wtmp have moved again, and
        should now be located in /var/run and /var/log respectively.
        Recommended practice is to add symlinks from their old locations
        so that your older programs will also find them.  Don't forget
        to check your startup scripts (/etc/bcheckrc, for example) to
        make sure you're not deleting things you shouldn't at startup.


      gcc: installation problem, cannot exec something: No such file or
        directory
        when attempting to do a.out compilations (something is usually
        one of cpp or cc1).  Either it's right, or alternatively you
        typed



          $ gcc -b -i486-linuxaout




     when you should have typed



          $ gcc -b i486-linuxaout




     Note that the `i486' does not start with a dash.



  3.  Building programs in ELF

  3.1.  Ordinary programs

  To build a program in ELF, use gcc as always.  To build in a.out, use
  gcc -b i486-linuxaout .








  ______________________________________________________________________
  $ cat >hello.c
  main() { printf("hello, world\n"); }
  ^D
  $ gcc -o hello hello.c
  $ file hello
  hello: ELF 32-bit LSB executable i386 (386 and up) Version 1
  $ ./hello
  hello, world
  ______________________________________________________________________




  This is perhaps an appropriate time to answer the question ``if a.out
  compilers default to producing a program called a.out, what name does
  an ELF compiler give its output?''.  Still a.out, is the answer.
  Boring boring boring ...  :-)


  3.2.  Building libraries

  To build libfoo.so as a shared library, the basic steps look like
  this:



       ______________________________________________________________________
       $ gcc -fPIC -c *.c
       $ gcc -shared -Wl,-soname,libfoo.so.1 -o libfoo.so.1.0 *.o
       $ ln -s libfoo.so.1.0 libfoo.so.1
       $ ln -s libfoo.so.1 libfoo.so
       $ export LD_LIBRARY_PATH=`pwd`:$LD_LIBRARY_PATH
       ______________________________________________________________________




  This will generate a shared library called libfoo.so.1.0, and the
  appropriate links for ld (libfoo.so) and the dynamic linker
  (libfoo.so.1) to find it.  To test, we add the current directory to
  LD_LIBRARY_PATH.

  When you're happpy that the library works, you'll have to move it to,
  say, /usr/local/lib, and recreate the appropriate links.  Note that
  the libfoo.so link should point to libfoo.so.1, so it doesn't need
  updating on every minor version number change.  The link from
  libfoo.so.1 to libfoo.so.1.0 is kept up to date by ldconfig, which on
  most systems is run as part of the boot process.



       ______________________________________________________________________
       $ su
       # cp libfoo.so.1.0 /usr/local/lib
       # /sbin/ldconfig
       # ( cd /usr/local/lib ; ln -s libfoo.so.1 libfoo.so )
       ______________________________________________________________________








  3.3.  Programs with dynamic loading

  These are covered extensively in H J Lu's ELF programming document,
  and the dlopen(3) manual page, which can be found in the ld.so
  package.  Here's a nice simple example though: link it with -ldl



       ______________________________________________________________________
       #include <dlfcn.h>
       #include <stdio.h>

       main()
       {
         void *libc;
         void (*printf_call)();

         if(libc=dlopen("/lib/libc.so.5",RTLD_LAZY))
         {
           printf_call=dlsym(libc,"printf");
           (*printf_call)("hello, world\n");
         }

       }
       ______________________________________________________________________





  3.4.  Debugging

  Your existing copy of gdb will most likely work unchanged with ELF
  programs.  The new version in the GCC directory on tsx-11 is reported
  to be better at debugging programs that use dynamic loading and to
  understand ELF core dumps.

  At the time of writing, a patch to the kernel is necessary before ELF
  programs will generate core dumps anyway, so it's perhaps a little
  academic.


  4.  Patches and binaries

  At this point in the proceedings, you can, if you like, stop.  You
  have installed everything necessary to compile and run ELF programs.

  You may wish to rebuild some programs in ELF, either for purposes of
  `neatness' or to minimise memory usage.  For most end-user
  applications, this is pretty simple; some packages however do assume
  too much about the systems they run on, and may fail due to one or
  more of:

  o  Different underscore conventions in the assembler: in an a.out
     executable, external labels get _ prefixed to them; in an ELF
     executable, they don't.  This makes no difference until you start
     integrating hand-written assembler: all the labels of the form _foo
     must be translated to foo, or (if you want to be portable about it)
     to EXTERNAL(foo) where EXTERNAL is some macro which returns either
     its argument (if __ELF__ is defined) or _ concatenated with its
     argument if not.

  o  Differences in libc 5 from libc 4.  The interface to the locale
     support has changed, for one.


  o  The application or build process depends on knowledge of the binary
     format used --- emacs, for example, dumps its memory image to disk
     in executable format, so obviously needs to know what format your
     executables are in.

  o  The application consists of or includes shared libraries (X11 is
     the obvious example).  These will obviously need changes to
     accomodate the different method of shared library creation in ELF.

  Anyway, here are two lists: the first is of programs that needed
  changing for ELF where the changes have been made (ie that you will
  need new versions of to compile as ELF), and the second is of programs
  that still need third-party patches of some kind.


  4.1.  Upgrade:


  o  Dosemu.  Modulo the three or four cuurrent dosemu development trees
     (don't ask, just join the linux-msdos mailing list), dosemu runs
     with ELF.  You'll need to monkey with the Makefile.  Current
     versions of dosemu are available from
     <ftp://tsx-11.mit.edu/pub/linux/ALPHA/dosemu/>

  o  Emacs.  Emacs has a rather odd build procedure that involves
     running a minimal version of itself, loading in all the useful bits
     as lisp, then dumping its memory image back to disk as an
     executable file.  (FSF) Emacs 19.29 and XEmacs 19.12 (formerly
     Lucid Emacs) can both detect whether you are compiling as ELF and
     Do The Right Thing automatically.

  o  MAKEDEV.  In some incarnations, this utility removes existing
     entries for devices before recreating them.  This is Bad News if it
     happens to touch /dev/zero, as said device is necessary to the
     operation of all ELF programs.  See the util-linux package(q.v.)
     for a fixed version.

  o  perl 5.001.  Perl 5.001 plus the ``official unofficial'' patches a-
     e will compile unchanged on an ELF system, complete with dynamic
     loading.  The patches are available from ftp.metronet.com or
     ftp.wpi.edu

  o  The cal program in util-linux 2.2 doesn't work.  Upgrade to version
     2.4 <ftp://tsx-11.mit.edu/pub/linux/packages/utils> or later.

  o  XFree86.  XFree86 3.1.2 comes in both a.out and ELF formats.  ftp
     to ftp.xfree86.org, read the `too many users' message that you are
     almost guaranteed to get, and pick the closest mirror site network-
     wise to you.

     I confess to not having actually tried this yet.  At time of
     writing, it's only been out for one day ;-)


  4.2.  Patch


  o  e2fsutils.  The Utilities for the Second Extended File System need
     a patch from
     <ftp://ftp.ibp.fr/pub/linux/ELF/patches/e2fsprogs-0.5b.elf.diff.gz>
     to compile correctly as a shared library.  Remy Card says ``This is
     the ELF patch which will probably be included in the next release
     of e2fsck and co''

  o  file.  This works anyway, but can be improved:
     <http://sable.ox.ac.uk/~jo95004/patches/file.diff> adds support for
     identifying stripped and mixed-endian ELF binaries.

  o  The Kernel.  As from at least 1.3.8, the development 1.3 series
     have a make config option to build using ELF tools.  If you are
     using the 1.2 series, you have two options:


     1. Patch the Makefile slightly to use the a.out compiler.  Just
        change the CC and LD definitions to be



          ___________________________________________________________________
          LD      =ld -m i386linux
          CC      =gcc -b i486-linuxaout -D__KERNEL__ -I$(TOPDIR)/include
          ___________________________________________________________________





     Alternatively,

     2. Apply H J Lu's patch which allows compiling the kernel in ELF
        (and also adds the ability to do ELF core dumps).


     Let me reiterate that neither of these is necessary for the 1.3
     series.

  o  ps (procps-0.97) The psupdate program needs a patch to work if you
     have compiled the kernel as ELF.  It's available in
     <linux.nrao.edu:/pub/people/juphoff/procps>, both as a patch to
     vanilla 0.97 and as an entire tar-file.  A new version of procps is
     expected to be released soon with this patch in place, so if you
     can find procps 0.98 by the time you read this, this patch will
     probably be obsolete.

  o  SVGATextMode requires a single simple adjustment.  Cut out the diff
     below and apply it, or else make the patch by hand.



       ______________________________________________________________________
       --- SVGATextMode-0.7.orig/XFREE/os-support/assyntax.h   Sun Feb 26 18:58:15 1995
       +++ SVGATextMode-0.7/XFREE/os-support/assyntax.h        Thu Mar 30 07:52:03 1995
       @@ -211,7 +211,7 @@
        #endif /* ACK_ASSEMBLER */


       -#if (defined(SYSV) || defined(SVR4)) && !defined(ACK_ASSEMBLER)
       +#if (defined (__ELF__) || defined(SYSV) || defined(SVR4)) && !defined(ACK_ASSEMBLER)
        #define GLNAME(a)       a
        #else
        #define GLNAME(a)       CONCAT(_,a)
       ______________________________________________________________________






  5.  Further information



  o  The linux-gcc mailing list is really the best place to see what's
     happening, usually without even posting to it.  Remember, it's not
     Usenet, so keep the questions down unless you're actually
     developing.  For instructions on joining the mailing list, mail a
     message containing the word help to majo...@vger.rutgers.edu

  o  There's a certain amount of information about what the linux-gcc
     list is doing at my ELF web page
     <http://sable.ox.ac.uk/~jo95004/elf.html>, when I remember to
     update it.  Archives of the list itself are at
     <http://homer.ncm.com/>.

  o  See also Bobby Shmit's ELF upgrade experience
     <http://www.intac.com/~cully/elf.html> web page.

  o  The GCC-FAQ <ftp://sunsite.unc.edu/pub/Linux/docs/faqs/GCC-
     FAQ.html> contains much general development information and some
     more technical ELF details.

  o  There's also documentation for the file format on tsx-11
     <ftp://tsx-11.mit.edu/pub/linux/packages/GCC/ELF.doc.tar.gz>.  This
     is probably of most use to people who want to understand, debug or
     rewrite programs that deal directly with binary objects.

  o  H J Lu's document ELF: From The Programmer's Perspective
     <ftp://tsx-11.mit.edu/pub/linux/packages/GCC/elf.latex.tar.gz>
     contains much useful and more detailed information on programming
     with ELF.  If you aren't LaTeX-capable, it is also available as
     PostScript.

  o  There is a manual page for dlopen(3) supplied with the ld.so
     package.


  6.  Legalese

  All trademarks used in this document are acknowledged as being owned
  by their respective owners.  (Spot the teeth-gritting irony there...)


  The right of Daniel Barlow to be identified as the author of this work
  has been asserted in accordance with sections 77 and 78 of the
  Copyright Designs and Patents Act 1988.  (Proof by assertion

  This document is copyright (C) 1995 Daniel Barlow
  <daniel...@sjc.ox.ac.uk> It may be reproduced and distributed in
  whole or in part, in any medium physical or electronic, as long as
  this copyright notice is retained on all copies. Commercial
  redistribution is allowed and encouraged; however, the author would
  like to be notified of any such distributions.

  All translations, derivative works, or aggregate works incorporating
  any Linux HOWTO documents must be covered under this copyright notice.
  That is, you may not produce a derivative work from a HOWTO and impose
  additional restrictions on its distribution. Exceptions to these rules
  may be granted under certain conditions; please contact the Linux
  HOWTO coordinator at the address given below.

  In short, we wish to promote dissemination of this information through
  as many channels as possible. However, we do wish to retain copyright
  on the HOWTO documents, and would like to be notified of any plans to
  redistribute the HOWTOs.

  If you have questions, please contact Greg Hankins, the Linux HOWTO
  coordinator, at gr...@sunsite.unc.edu via email, or at +1 404 853
  9989.

- --- END Linux ELF HOWTO part 1/1 ---

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: finger gr...@cc.gatech.edu for public key

iQCVAwUBMFYPA3tNTo2suu5NAQHD8AQAi5g0MxU4p5hMGeKDR52jkNzvQhGd4CnG
qvbAZRVkrejMtTDbSk0yWf2HYEpdH3zlKOaQzu3dVfAWopCXJe3wtIqg7mR7bk6m
ZzEGLoSLm/B4nvMqO3NKGyhfsZgCn7N67lmEEtynohQi9wqtTKu3uNeBnWLdRUsG
GV0oYNzTLZk=
=ayt5
-----END PGP SIGNATURE-----

From: Daniel Barlow <daniel...@sjc.ox.ac.uk>
Subject: Linux ELF HOWTO
Date: 1995/10/02
Message-ID: <ELF-HOWTO.1-15652.812660189@cc.gatech.edu>
X-Deja-AN: 116904586
approved: linux-...@news.ornl.gov (Matt Welsh)
sender: gr...@cc.gatech.edu
followup-to: poster
summary: How to install and migrate to the ELF binary file format
organization: Linux HOWTO Project
keywords: Linux, HOWTO, ELF
newsgroups: comp.os.linux.answers,comp.os.linux.development.system,comp.os.linux.setup
nntp-posting-user: gregh

Archive-Name: linux/howto/elf
Last-modified: 2 Oct 95

-----BEGIN PGP SIGNED MESSAGE-----

*** The Linux ELF HOWTO is posted automatically by the Linux
*** HOWTO coordinator, Greg Hankins <gr...@sunsite.unc.edu>.  Please
*** direct any comments or questions about this HOWTO to the author,
*** Daniel Barlow <daniel...@sjc.ox.ac.uk>.

- --- BEGIN Linux ELF HOWTO part 1/1 ---

  The Linux ELF HOWTO
  Daniel Barlow <daniel...@sjc.ox.ac.uk>
  v1.11, 13 September 1995

  This document describes how to migrate your Linux system to compile
  and run programs in the ELF binary format.  It falls into three con-
  ceptual parts: (1) What ELF is, and why/whether you should upgrade,
  (2) How to upgrade to ELF-capability, and (3) what you can do then.

  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:


  o  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 com-
  piling 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).

  o  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?


  2.  Installation

  2.1.  Background

  The aim of this conversion is to leave you with a system which can
  build and run both a.out and ELF programs, with each type of program
  being able to find its appropriate breed of shared libraries.  This
  obviously requires a bit more intelligence in the library search
  routines than the simple `look in /lib, /usr/lib and anywhere else
  that the program was compiled to search' strategy that some other
  systems can get away with.

  The beastie responsible for searching out libraries in linux is
  /lib/ld.so.  The compiler and linker do not encode absolute library
  pathnames into the programs they output; instead they put the library
  name and the absolute path to ld.so in, and leave ld.so to match the
  library name to the appropriate place at runtime.  This has one very
  important effect --- it means that the libraries that a program uses
  can be moved to other directories without recompiling the program,
  provided that ld.so is told to search the new directory.  This is
  essential functionality for the directory swapping operation that
  follows.

  The corollary of the above, of course, is that any attempt to delete
  or move ld.so will cause every dynamically linked program on the
  system to stop working.  This is generally regarded as a Bad Thing.

  For ELF binaries, an alternate dynamic loader is provided.  This is
   /lib/ld-linux.so.1, and does exactly the same thing as ld.so, but for
  ELF programs.  ld-linux.so.1 uses the same support files and programs
  (ldd, ldconfig, and /etc/ld.so.conf) as the a.out loader ld.so does.

  The basic plan, then, is that ELF development things (compilers,
  include files and libraries) go into /usr/{bin,lib,include} where your
  a.out ones currently are, and the a.out things will be moved into
  /usr/i486-linuxaout/{bin, lib, include}.  /etc/ld.so.conf lists all
  the places on the system where libraries are expected to be found, and
  ldconfig is intelligent enough to distinguish between ELF and a.out
  variants.

  There are a couple of exceptions to the library placement, though.

  o  Some old programs were built without the use of ld.so.  These would
     all cease working if their libraries were moved from under them.
     Thus, libc.so* and libm.so* must stay where they are in /lib, and
     the ELF versions have had their major numbers upgraded so that they
     do not overwrite the a.out ones.  Old X libraries (prior to version
     6) are best left where they are also, although newer ones
     (libX*so.6) must be moved.  Moving the old ones will apparently
     break xview programs, and not moving the new ones will cause them
     to be overwritten when you install ELF X libraries.

     If you have non-ld.so programs that require libraries other than
     the above (if you know which programs they are, you can run ldd on
     them to find out which libraries they need before breaking them)
     you have essentially two options.  One, you can extract the ELF
     library tar files into a temporary directory, check whether your
     precious library would be overwritten, and if so, move the ELF
     version of the library into, say, /usr/i486-linux/lib instead of
     /lib.  Make sure your ld.so.conf has /usr/i486-linux/lib in it,
     then run ldconfig and think no more on't.  Two, you can recompile
     or acquire a newer copy of the offending program.  This might not
     be a bad idea, if possible.

  o  If you have /usr and / on different partitions, you'll need to move
     at least some of the libraries in /lib to somewhere on the root
     disk, not on /usr.  Either you can go through the programs that you
     need to run at system startup or when in single-user mode, and
     identify the libraries they use, or you can depend on your
     system/distribution integrator to have done this for you and just
     move all (er ... some.  See above for the exceptions) of the
     libraries in /lib to /lib-aout.


  2.2.  Before you start --- Notes and Caveats


  o  You will need to be running a post-1.1.52 kernel with ELF binary
     format support.

  o  You are recommended to prepare or acquire a linux boot/root disk,
     such as a Slackware rescue disk.  You probably won't need it, but
     if you do and you don't have one, you'll kick yourself.  In a
     similar `prevention is better than cure' vein, statically linked
     copies of mv, ln, and maybe other file manipulation commands
     (though in fact I think you can do everything else you actually
     need to with shell builtins) may help you out of any awkward
     situations you could end up in.

  o  If you have been following the ELF development, you may have ELF
     libraries in /lib/elf (usually libc.so.4 and co).  Applications
     that you built using these should be rebuilt, then the directory
     removed.  There is no need for a /lib/elf directory!

  o  Most Linux installations these days have converged on the `FSSTND'
     standard file system, but doubtless there are still installed
     systems that haven't.  If you see references to /sbin/something and
     you don't have a /sbin directory, you'll probably find the program
     referred to in /bin or /etc/.


  2.3.  You will need ...

  The following packages are available from
  <ftp://tsx-11.mit.edu/pub/linux/packages/GCC/> and
  <ftp://sunsite.unc.edu/pub/Linux/GCC/>.  Both sites are widely
  mirrored; please take the time to look up your nearest mirror site and
  use that instead of the master sites where possible.  It's faster for
  both you and everyone else.

  These packages (either the listed version or a later one) are
  required.  Also download and read through the release notes for each
  of them: these are the files named release.packagename.  This applies
  especially if you get newer versions than are listed here, as
  procedures may have changed.

  o  ld.so-1.7.3.tar.gz --- the new dynamic linker

  o  libc-5.0.9.bin.tar.gz --- the ELF shared images for the C library
     and its friends (m (maths), termcap, gdbm, and so on), plus the
     corresponding static libraries and the include files needed to
     compile programs with them.  libc 5.2.something is expected to be
     released during the lifetime of this HOWTO, and is considerably
     different from 5.0.9; if you want to install it, you're on your
     own, but I'd recommend installing 5.0.9 first and then installing
     it over the top.  There are several parts to libc 5.0.9 which are
     not included in 5.2.x and for which the distribution channels are
     not entirely set up yet.

  o  gcc-2.7.0.bin.tar.gz --- the ELF C compiler.  Also includes an
     a.out C compiler which understands the new directory layout.

  o  binutils-2.5.2l.17.bin.tar.gz --- the GNU binary utilities patched
     for Linux.  These are programs such as gas, ld, strings and so on,
     most of which are required to make the C compiler go.


  2.4.  Rearranging your filesystem

  Sooo...  Note that in all that follows, when I say `remove' I
  naturally mean `backup then remove' :-).  Also, these instructions
  directly apply only to people who haven't yet messed with ELF ---
  those who have are expected to have the necessary nous to adapt as
  appropriate.  Let's go!


  1. Make the new directories that you will move a.out things to


       ______________________________________________________________________
       mkdir -p /usr/i486-linuxaout/bin
       mkdir -p /usr/i486-linuxaout/include
       mkdir -p /usr/i486-linuxaout/lib
       mkdir /lib-aout
       ______________________________________________________________________





  2. Untar the dynamic linker package ld.so-1.7.3 in the directory you
     usually put source code, then read through the
     ld.so-1.7.3/instldso.sh script just unpacked.  If you have a really
     standard system, run it by doing sh instldso.sh, but if you have
     anything at all unusual then do the install by hand instead.
     `Anything at all unusual' includes

  o  using zsh as a shell (some versions of zsh define $VERSION, which
     seems to confuse instldso.sh)

  o  having symlinks from /lib/elf to /lib (which you shouldn't need,
     but you may have valid reasons for if you have been following the
     ELF development)


  3. Edit /etc/ld.so.conf to add the new directory
     /usr/i486-linuxaout/lib (and /lib-aout if you're going to need
     one).  Then rerun /sbin/ldconfig -v to check that it is picking up
     the new directories.

  4. Move all the a.out libraries in /usr/*/lib to
     /usr/i486-linuxaout/lib.  Note, I said `libraries' not
     `everything'.  That's files matching the specification lib*.so* ,
     lib*.sa*, or lib*.a.  Don't start moving /usr/lib/gcc-lib or
     anything silly like that around.

  5. Now look at /lib.  Leave intact libc.so*, libm.so*, and libdl.so*.
     If you have symlinks to X libraries (libX*.so.3*) leave them there
     too --- XView and some other packages may require them.  Leave
     ld.so*, ld-linux.so* and any other files starting with ld.  As for
     the remaining libraries (if you have any left): if you have /usr on
     the root partition, put them in /usr/i486-linuxaout/lib.  If you
     have /usr mounted separately, put them in /lib-aout.  Now run
     ldconfig -v

  6. Remove the directory /usr/lib/ldscripts if it's there, in
     preparation for installing the binutils (which will recreate it)

  7. Remove any copies of ld and as (except for ld86 and as86) that you
     can find in /usr/bin.

  8. Some versions of GNU tar appear to have problems dealing with
     symbolic links in the destination directory.  You have two options
     here:


     a. (preferred) Use cpio instead of tar, it doesn't have this
        problem.  zcat /wherever/you/put/it/libc-5.0.9.tar.gz | cpio -iv
        is the magic incantation here, to be executed from the root
        directory.

     b. (if you don't have cpio installed) Before installing the libc
        images you might want to go through /usr/include and remove some
        parts.

        This is icky.  Many packages (such as ncurses) are installed
        into /usr/include by distribution maintainers and are not
        supplied with the C library.  Backup the /usr/include tree, use
        tar tzf to see what's in the archive before untarring it, then
        delete the bits of /usr/include that it actually fills.  Then
        untar the libc-5.0.9.bin.tar.gz  package from root.


  9. Install the binutils package.  tar -xvzf
     binutils-2.5.2.l17.bin.tar.gz -C /  is one perfectly good way to do
     this.

  10.
     You have now installed everything you need to run ELF executables.
     Medical experts recommend that VDU workers take regular breaks away
     from the screen; this would be an opportune moment.  Don't forget
     what you were doing, though; depending on the version of gcc you
     were previously using, you may have left yourself unable to compile
     programs in a.out until you unpack the new gcc.

  11.
     Backup and remove everything in /usr/lib/gcc-lib/{i486-linux,
     i486-linuxelf, i486-linuxaout}/  If you use a non-standard gcc
     driver (eg if you use Gnu ADA), copy that somewhere safe also.
     Then install the gcc package, again by untarring from root.

  12.
     Some programs (notably various X programs) use /lib/cpp, which
     under Linux is generally a link to /usr/lib/gcc-
     lib/i486-linux/version/cpp.  As the preceding step wiped out
     whatever version of cpp it was pointing to, you'll need to recreate
     the link:

       $ cd /lib
       $ ln -s /usr/lib/gcc-lib/i486-linux/2.7.0/cpp .





  13.
     The FSSTND people have once again justified their keep by moving
     the utmp and wtmp files from /var/adm to /var/run and /var/log
     respectively.  You'll need to add some links dependent on where
     they currently live, and you may need to make the /var/log and
     /var/adm directories too.  I reproduce below the ls -l output of
     appropriate bits on my system:



       $ ls -ld /var/adm /var/log /var/run /var/log/*tmp /var/run/*tmp
       lrwxrwxrwx   1 root     root            3 May 24 05:53 /var/adm -> log/
       drwxr-xr-x   9 root     root         1024 Aug 13 23:17 /var/log/
       lrwxrwxrwx   1 root     root           11 Aug 13 23:17 /var/log/utmp -> ../run/utmp
       -rw-r--r--   1 root     root       451472 Aug 13 23:00 /var/log/wtmp
       drwxr-xr-x   2 root     root         1024 Aug 13 23:17 /var/run/
       -rw-r--r--   1 root     root          448 Aug 13 23:00 /var/run/utmp





  Check the FSSTND (from LDP archives such as
  <ftp://sunsite.unc.edu/pub/Linux/docs/fsstnd/>) for the full story.

  14.
     This step is optional.  If you're intending to continue compiling
     programs in a.out, this is the appropriate time to install libc.so
     4.7.x.  Untar it from root, as you are now no doubt fully capable
     of doing without further explanation.

   Done!  Simple tests that you can try are



       ______________________________________________________________________
       $ gcc -v
       Reading specs from /usr/lib/gcc-lib/i486-linux/2.7.0/specs
       gcc version 2.7.0
       $ gcc -v -b i486-linuxaout
       Reading specs from /usr/lib/gcc-lib/i486-linuxaout/2.7.0/specs
       gcc version 2.7.0
       $ ld -V
       ld version cygnus/linux-2.5.2l.14 (with BFD cygnus/linux-2.5.2l.11)
         Supported emulations:
          elf_i386
          i386linux
          i386coff
       ______________________________________________________________________




  followed of course by the traditional ``Hello, world'' program.  Try
  it with gcc and with gcc -b i486-linuxaout to check that both the
  a.out and ELF compilers are set up corectly.



  2.5.  What it should look like (outline directory structure)

  This is a deliberately vague guide to what the files you have just
  installed are.  It may be useful for troubleshooting or deciding what
  to delete.


  2.5.1.
   /lib


  o  Dynamic linkers ld.so (a.out) and ld-linux.so.1 (ELF).  Either of
     these may be symlinks, but make sure that the files they point to
     do exist.

  o  Basic shared libraries libc.so.4, libm.so.4 (a.out) These are
     symlinks, but check that they point to real files.

  o  Basic shared libraries libc.so.5, libm.so.5,
     libdl.so.1,libcurses.so.1,libtermcap.so.2, (ELF).  Again, these are
     symlinks.

  o  Lots of symlinks.  For each library, there should be an actual file
     (for example libc.so.5.0.9), a symlink to it with only the major
     version number in its name (libc.so.5) and a symlink pointing to
     that with no version number (libc.so).  That's



       ______________________________________________________________________
       lrwxrwxrwx   1 root  root      9 May 24 05:52 libc.so -> libc.so.5
       lrwxrwxrwx   1 root  root     13 Aug 25 12:48 libc.so.5 -> libc.so.5.0.9
       -rwxr-xr-x   1 bin   bin  562683 May 19 04:47 libc.so.5.0.9
       ______________________________________________________________________






  2.5.2.  /usr/lib


  o  All the non-library files and directories that were there
     previously.

  o  libbfd.so*,libdb.so*, libgdbm.so*, ELF shared libraries.  All to
     consist of three files as explained above in the /lib section.

  o  libbsd.a, libgmon.a, libldso.a, libmcheck.a, libieee.a, libmcheck.a
     and one lib*.a file for every ELF shared library in /lib and
     /usr/lib .  ELF static libraries.  The ones duplicating the shared
     libraries may not be tremendously useful for most people --- when
     using ELF, you can use the gcc -g switch with shared libraries, so
     there's not much reason to compile static any longer.

  o  crt0.o, gcrt0.o.  a.out `start of program' files; one of these is
     linked as the first file in every a.out program you compile, unless
     you take steps to avoid it.

  o  crt1.o, crtbegin.o, crtbeginS.o, crtend.o, crtendS.o, crti.o,
     crtn.o, gcrt1.o.  ELF startup files.  These do similar things to
     *crt0.o above for ELF programs.



  2.5.3.
   /usr/lib/ldscripts


  o  This is where the driver scripts for ld live, as the name suggests.
     It should look like


       ______________________________________________________________________
       $ ls /usr/lib/ldscripts/
       elf_i386.x      elf_i386.xs     i386coff.xn     i386linux.xbn
       elf_i386.xbn    elf_i386.xu     i386coff.xr     i386linux.xn
       elf_i386.xn     i386coff.x      i386coff.xu     i386linux.xr
       elf_i386.xr     i386coff.xbn    i386linux.x     i386linux.xu
       ______________________________________________________________________





  2.5.4.  /usr/i486-linux/bin


  o  ar, as, gasp, ld, nm, ranlib, strip.  These are all actually
     symlinks to the real binutils in /usr/bin


  2.5.5.  /usr/i486-linuxaout/bin


  o  as --- the a.out assembler, and gasp, its macro preprocessor

  o  ar, ld, nm, ranlib, strip --- symlinks to the real binutils in
     /usr/bin


  2.5.6.  /usr/i486-linux/lib


  o  ldscripts is a symlink to /usr/lib/ldscripts.


  2.5.7.  /usr/i486-linuxaout/lib


  o  lib*.so*. a.out shared library images.  Needed to run a.out
     programs

  o  lib*.sa. a.out shared library stubs.  Needed to compile a.out
     programs that use shared libraries.  If you don't intend to, you
     can safely remove these.

  o  lib*.a. a.out static libraries.  Needed to compile static a.out
     programs (eg when compiling with -g).  Again, you can delete them
     if you don't intend to.

  o  ldscripts is a symbolic link to /usr/lib/ldscripts


  2.5.8.  /usr/lib/gcc-lib/i486-linux/2.7.0


  o  This directory contains a version of gcc 2.7.0 set up to compile
     ELF programs.


  2.5.9.  /usr/lib/gcc-lib/i486-linuxaout/2.7.0


  o  This directory contains a version of gcc 2.7.0 set up to compile
     a.out programs, which knows about the new directory structure.  If
     you're not going to compile anything in a.out, deleting this may
     free up around 4Mb.


  2.6.  Common errors (Don't Panic!)




      You moved the wrong thing and now nothing runs
        You still have a shell running, though, and with a little
        ingenuity you can do an awful lot with shell builtins.  Remember
        that echo * is an acceptable substitute for ls, and echo
        >>filename can be used to add lines to a file.  Also, don't
        forget that ldconfig is linked static.  If you moved, say,
        libc.so.4 to /lib-aout mistakenly, you can do echo "lib-aout"
        >>/etc/ld.so.conf ; ldconfig -v/ and be back up again.  If you
        moved /lib/ld.so you may be able to do sln /silly/place/ld.so
        /lib/ld.so, if you have a statically linked ln, and probably be
        back up again.


      no such file or directory: /usr/bin/gcc
        that the ELF dynamic loader /lib/ld-linux.so.1 is not installed,
        or is unreadable for some reason.  You should have installed it
        at around step 2 previously.


      not a ZMAGIC file, skipping
        from ldconfig.  You have an old version of the ld.so package, so
        get a recent one.  Again, see step 2 of the installation.


      bad address
        on attempting to run anything ELF.  You're using kernel 1.3.x,
        where x<3.  Upgrade to 1.3.3 or downgrade to 1.2.something


      _setutent: Can't open utmp file
        This message is often seen in multiples of three when you start
        an xterm.  Go and read the FSSTND tirade near the end of the
        installation procedure.


      gcc: installation problem, cannot exec something: No such file or
        directory
        when attempting to do a.out compilations (something is usually
        one of cpp or cc1).  Either it's right, or alternatively you
        typed



          $ gcc -b -i486-linuxaout




     when you should have typed



     $ gcc -b i486-linuxaout




     Note that the `i486' does not start with a dash.



  3.  Building programs in ELF

  3.1.  Ordinary programs

  To build a program in ELF, use gcc as always.  To build in a.out, use
  gcc -b i486-linuxaout .



       ______________________________________________________________________
       $ cat >hello.c
       main() { printf("hello, world\n"); }
       ^D
       $ gcc -o hello hello.c
       $ file hello
       hello: ELF 32-bit LSB executable i386 (386 and up) Version 1
       $ ./hello
       hello, world
       ______________________________________________________________________




  This is perhaps an appropriate time to answer the question ``if a.out
  compilers default to producing a program called a.out, what name does
  an ELF compiler give its output?''.  Still a.out, is the answer.
  Boring boring boring ...  :-)


  3.2.  Building libraries

  To build libfoo.so as a shared library, the basic steps look like
  this:



       ______________________________________________________________________
       $ gcc -fPIC -c *.c
       $ gcc -shared -Wl,-soname,libfoo.so.1 -o libfoo.so.1.0 *.o
       $ ln -s libfoo.so.1.0 libfoo.so.1
       $ ln -s libfoo.so.1 libfoo.so
       $ export LD_LIBRARY_PATH=`pwd`:$LD_LIBRARY_PATH
       ______________________________________________________________________




  This will generate a shared library called libfoo.so.1.0, and the
  appropriate links for ld (libfoo.so) and the dynamic linker
  (libfoo.so.1) to find it.  To test, we add the current directory to
  LD_LIBRARY_PATH.

  When you're happpy that the library works, you'll have to move it to,
  say, /usr/local/lib, and recreate the appropriate links.  Note that
  the libfoo.so link should point to libfoo.so.1, so it doesn't need
  updating on every minor version number change.  The link from
  libfoo.so.1 to libfoo.so.1.0 is kept up to date by ldconfig, which on
  most systems is run as part of the boot process.



       ______________________________________________________________________
       $ su
       # cp libfoo.so.1.0 /usr/local/lib
       # /sbin/ldconfig
       # ( cd /usr/local/lib ; ln -s libfoo.so.1 libfoo.so )
       ______________________________________________________________________





  3.3.  Programs with dynamic loading

  These are covered extensively in H J Lu's ELF programming document,
  and the dlopen(3) manual page, which can be found in the ld.so
  package.  Here's a nice simple example though: link it with -ldl



       ______________________________________________________________________
       #include <dlfcn.h>
       #include <stdio.h>

       main()
       {
         void *libc;
         void (*printf_call)();

         if(libc=dlopen("/lib/libc.so.5",RTLD_LAZY))
         {
           printf_call=dlsym(libc,"printf");
           (*printf_call)("hello, world\n");
         }

       }
       ______________________________________________________________________





  3.4.  Debugging

  Your existing copy of gdb will most likely work unchanged with ELF
  programs.  The new version in the GCC directory on tsx-11 is reported
  to be better at debugging programs that use shared libraries and
  dynamic loading, and to understand ELF core dumps.

  Note that 1.2 series kernels cannot generate core dumps from ELF
  programs anyway.  1.3 can.


  4.  Patches and binaries

  At this point in the proceedings, you can, if you like, stop.  You
  have installed everything necessary to compile and run ELF programs.

  You may wish to rebuild some programs in ELF, either for purposes of
  `neatness' or to minimise memory usage.  For most end-user
  applications, this is pretty simple; some packages however do assume
  too much about the systems they run on, and may fail due to one or
  more of:
  o  Different underscore conventions in the assembler: in an a.out
     executable, external labels get _ prefixed to them; in an ELF
     executable, they don't.  This makes no difference until you start
     integrating hand-written assembler: all the labels of the form _foo
     must be translated to foo, or (if you want to be portable about it)
     to EXTERNAL(foo) where EXTERNAL is some macro which returns either
     its argument (if __ELF__ is defined) or _ concatenated with its
     argument if not.

  o  Differences in libc 5 from libc 4.  The interface to the locale
     support has changed, for one.

  o  The application or build process depending on knowledge of the
     binary format used --- emacs, for example, dumps its memory image
     to disk in executable format, so obviously needs to know what
     format your executables are in.

  o  The application consists of or includes shared libraries (X11 is
     the obvious example).  These will obviously need changes to
     accomodate the different method of shared library creation in ELF.

  Anyway, here are two lists: the first is of programs that needed
  changing for ELF where the changes have been made (ie that you will
  need new versions of to compile as ELF), and the second is of programs
  that still need third-party patches of some kind.


  4.1.  Upgrade:


  o  Dosemu.  Modulo the three or four cuurrent dosemu development trees
     (don't ask, just join the linux-msdos mailing list), dosemu runs
     with ELF.  You'll need to monkey with the Makefile.  Current
     versions of dosemu are available from
     <ftp://tsx-11.mit.edu/pub/linux/ALPHA/dosemu/>

  o  Emacs.  Emacs has a rather odd build procedure that involves
     running a minimal version of itself, loading in all the useful bits
     as lisp, then dumping its memory image back to disk as an
     executable file.  (FSF) Emacs 19.29 and XEmacs 19.12 (formerly
     Lucid Emacs) can both detect whether you are compiling as ELF and
     Do The Right Thing automatically.

  o  MAKEDEV.  In some incarnations, this utility removes existing
     entries for devices before recreating them.  This is Bad News if it
     happens to touch /dev/zero, as said device is necessary to the
     operation of all ELF programs.  See the util-linux package(q.v.)
     for a fixed version.

  o  perl 5.001.  Perl 5.001 plus the ``official unofficial'' patches a-
     e will compile unchanged on an ELF system, complete with dynamic
     loading.  The patches are available from ftp.metronet.com or
     ftp.wpi.edu

  o  The cal program in util-linux 2.2 doesn't work.  Upgrade to version
     2.4 <ftp://tsx-11.mit.edu/pub/linux/packages/utils> or later.

  o  XFree86.  XFree86 3.1.2 comes in both a.out and ELF formats.  ftp
     to ftp.xfree86.org, read the `too many users' message that you are
     almost guaranteed to get, and pick the closest mirror site network-
     wise to you.  Once you have the contents of the common and elf
     directories, you must edit /usr/X11R6/lib/X11/config/linux.cf to
     change the lines saying



  #define LinuxElfDefault         NO
  #define UseElfFormat            NO





  to say YES instead.  Otherwise an xpm build will attempt to do odd
  stuff with jumpas and its associated relics of the past.

  o  Mosaic.  I don't have the facilities to build this myself, but the
     Mosaic 2.7b1 binary available from NCSA comes in ELF.  It has been
     linked against an odd X setup though, with the result that on
     normal systems it will complain about not finding libXpm.so.4.5.
     The simple fix is to edit it carefully with emacs or another editor
     that copes with binary files.  Find the occurence of the string
     libXpm.so.4.5^@ (where ^@ is a NUL --- ASCII zero --- character),
     delete the .5 and add two more characters after the NUL to aviod
     changing the file length.


  4.2.  Patch


  o  e2fsutils.  The Utilities for the Second Extended File System need
     a patch from
     <ftp://ftp.ibp.fr/pub/linux/ELF/patches/e2fsprogs-0.5b.elf.diff.gz>
     to compile correctly as a shared library.  Remy Card says ``This is
     the ELF patch which will probably be included in the next release
     of e2fsck and co''

  o  file.  This works anyway, but can be improved:
     <http://sable.ox.ac.uk/~jo95004/patches/file.diff> adds support for
     identifying stripped and mixed-endian ELF binaries.

  o  The Kernel.  As from at least 1.3.8, the development 1.3 series
     have a make config option to build using ELF tools.  If you are
     using the 1.2 series, you have two options:


     1. Patch the Makefile slightly to use the a.out compiler.  Just
        change the CC and LD definitions to be



          ___________________________________________________________________
          LD      =ld -m i386linux
          CC      =gcc -b i486-linuxaout -D__KERNEL__ -I$(TOPDIR)/include
          ___________________________________________________________________





     Alternatively,

     2. Apply H J Lu's patch which allows compiling the kernel in ELF
        (and also adds the ability to do ELF core dumps).


     Let me reiterate that neither of these is necessary for the 1.3
     series.

  o  ps (procps-0.97) The psupdate program needs a patch to work if you
     have compiled the kernel as ELF.  It's available in
     <linux.nrao.edu:/pub/people/juphoff/procps>, both as a patch to
     vanilla 0.97 and as an entire tar-file.  A new version of procps is
     expected to be released soon with this patch in place, so if you
     can find procps 0.98 by the time you read this, this patch will
     probably be obsolete.


  5.  Further information



  o  The linux-gcc mailing list is really the best place to see what's
     happening, usually without even posting to it.  Remember, it's not
     Usenet, so keep the questions down unless you're actually
     developing.  For instructions on joining the mailing list, mail a
     message containing the word help to majo...@vger.rutgers.edu.
     Archives of the list are at  .

  o  There's a certain amount of information about what the linux-gcc
     list is doing at my ELF web page
     <http://sable.ox.ac.uk/~jo95004/elf.html>, when I remember to
     update it.  This also has a link to the latest version of this
     HOWTO, and the patches it refers to.  For US people and others with
     poor links to UK academic sites (that's nearly everyone outside of
     UK academia), this is all mirrored at
     <http://www.blackdown.org/elf/elf.html>

  o  See also Bobby Shmit's ELF upgrade experience
     <http://www.intac.com/~cully/elf.html> web page.

  o  The GCC-FAQ <ftp://sunsite.unc.edu/pub/Linux/docs/faqs/GCC-
     FAQ.html> contains much general development information and some
     more technical ELF details.

  o  There's also documentation for the file format on tsx-11
     <ftp://tsx-11.mit.edu/pub/linux/packages/GCC/ELF.doc.tar.gz>.  This
     is probably of most use to people who want to understand, debug or
     rewrite programs that deal directly with binary objects.

  o  H J Lu's document ELF: From The Programmer's Perspective
     <ftp://tsx-11.mit.edu/pub/linux/packages/GCC/elf.latex.tar.gz>
     contains much useful and more detailed information on programming
     with ELF.  If you aren't LaTeX-capable, it is also available as
     PostScript.

  o  There is a manual page for dlopen(3) supplied with the ld.so
     package.


  6.  Legalese

  All trademarks used in this document are acknowledged as being owned
  by their respective owners.  (Spot the teeth-gritting irony there...)


  The right of Daniel Barlow to be identified as the author of this work
  has been asserted in accordance with sections 77 and 78 of the
  Copyright Designs and Patents Act 1988.  (Proof by assertion

  This document is copyright (C) 1995 Daniel Barlow
  <daniel...@sjc.ox.ac.uk> It may be reproduced and distributed in
  whole or in part, in any medium physical or electronic, as long as
  this copyright notice is retained on all copies. Commercial
  redistribution is allowed and encouraged; however, the author would
  like to be notified of any such distributions.


  All translations, derivative works, or aggregate works incorporating
  any Linux HOWTO documents must be covered under this copyright notice.
  That is, you may not produce a derivative work from a HOWTO and impose
  additional restrictions on its distribution. Exceptions to these rules
  may be granted under certain conditions; please contact the Linux
  HOWTO coordinator at the address given below.

  In short, we wish to promote dissemination of this information through
  as many channels as possible. However, we do wish to retain copyright
  on the HOWTO documents, and would like to be notified of any plans to
  redistribute the HOWTOs.

  If you have questions, please contact Greg Hankins, the Linux HOWTO
  coordinator, at gr...@sunsite.unc.edu via email, or at +1 404 853
  9989.

- --- END Linux ELF HOWTO part 1/1 ---

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: finger gr...@cc.gatech.edu for public key

iQCVAwUBMHA1zntNTo2suu5NAQFp7wP9G3E2Sna5vXtKv0CzTggqwfGwi0zHvkCk
tJCZYL+dK2mGtjGJHKoBWi+RDq5uDTOlF5mAZe0oeF3APaiYPNdptk8TXS5rMJby
4Yk9K9VJ84WSwmPcocp6V2KKxU+R1zLyhYtf8TO6erero+u2RTTOucuc+zF9d1Qk
pERCRAaM7CE=
=DlsP
-----END PGP SIGNATURE-----

From: Daniel Barlow <daniel...@sjc.ox.ac.uk>
Subject: Linux ELF HOWTO
Date: 1995/11/02
Message-ID: <ELF-HOWTO.1-19781.815328746@cc.gatech.edu>
X-Deja-AN: 118655840
approved: linux-...@news.ornl.gov (Matt Welsh)
sender: gr...@cc.gatech.edu
followup-to: poster
summary: How to install and migrate to the ELF binary file format
organization: Linux HOWTO Project
keywords: Linux, HOWTO, ELF
newsgroups: comp.os.linux.answers,comp.os.linux.development.system,comp.os.linux.setup
nntp-posting-user: gregh

Archive-Name: linux/howto/elf
Last-modified: 30 Oct 95

-----BEGIN PGP SIGNED MESSAGE-----

*** The Linux ELF HOWTO is posted automatically by the Linux
*** HOWTO coordinator, Greg Hankins <gr...@sunsite.unc.edu>.  Please
*** direct any comments or questions about this HOWTO to the author,
*** Daniel Barlow <daniel...@sjc.ox.ac.uk>.

- --- BEGIN Linux ELF HOWTO part 1/1 ---

  The Linux ELF HOWTO
  Daniel Barlow <daniel...@sjc.ox.ac.uk>
  v1.11, 13 September 1995

  This document describes how to migrate your Linux system to compile
  and run programs in the ELF binary format.  It falls into three con-
  ceptual parts: (1) What ELF is, and why/whether you should upgrade,
  (2) How to upgrade to ELF-capability, and (3) what you can do then.

  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:


  o  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 com-
  piling 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).

  o  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?


  2.  Installation

  2.1.  Background

  The aim of this conversion is to leave you with a system which can
  build and run both a.out and ELF programs, with each type of program
  being able to find its appropriate breed of shared libraries.  This
  obviously requires a bit more intelligence in the library search
  routines than the simple `look in /lib, /usr/lib and anywhere else
  that the program was compiled to search' strategy that some other
  systems can get away with.

  The beastie responsible for searching out libraries in linux is
  /lib/ld.so.  The compiler and linker do not encode absolute library
  pathnames into the programs they output; instead they put the library
  name and the absolute path to ld.so in, and leave ld.so to match the
  library name to the appropriate place at runtime.  This has one very
  important effect --- it means that the libraries that a program uses
  can be moved to other directories without recompiling the program,
  provided that ld.so is told to search the new directory.  This is
  essential functionality for the directory swapping operation that
  follows.

  The corollary of the above, of course, is that any attempt to delete
  or move ld.so will cause every dynamically linked program on the
  system to stop working.  This is generally regarded as a Bad Thing.

  For ELF binaries, an alternate dynamic loader is provided.  This is
   /lib/ld-linux.so.1, and does exactly the same thing as ld.so, but for
  ELF programs.  ld-linux.so.1 uses the same support files and programs
  (ldd, ldconfig, and /etc/ld.so.conf) as the a.out loader ld.so does.

  The basic plan, then, is that ELF development things (compilers,
  include files and libraries) go into /usr/{bin,lib,include} where your
  a.out ones currently are, and the a.out things will be moved into
  /usr/i486-linuxaout/{bin, lib, include}.  /etc/ld.so.conf lists all
  the places on the system where libraries are expected to be found, and
  ldconfig is intelligent enough to distinguish between ELF and a.out
  variants.

  There are a couple of exceptions to the library placement, though.

  o  Some old programs were built without the use of ld.so.  These would
     all cease working if their libraries were moved from under them.
     Thus, libc.so* and libm.so* must stay where they are in /lib, and
     the ELF versions have had their major numbers upgraded so that they
     do not overwrite the a.out ones.  Old X libraries (prior to version
     6) are best left where they are also, although newer ones
     (libX*so.6) must be moved.  Moving the old ones will apparently
     break xview programs, and not moving the new ones will cause them
     to be overwritten when you install ELF X libraries.

     If you have non-ld.so programs that require libraries other than
     the above (if you know which programs they are, you can run ldd on
     them to find out which libraries they need before breaking them)
     you have essentially two options.  One, you can extract the ELF
     library tar files into a temporary directory, check whether your
     precious library would be overwritten, and if so, move the ELF
     version of the library into, say, /usr/i486-linux/lib instead of
     /lib.  Make sure your ld.so.conf has /usr/i486-linux/lib in it,
     then run ldconfig and think no more on't.  Two, you can recompile
     or acquire a newer copy of the offending program.  This might not
     be a bad idea, if possible.

  o  If you have /usr and / on different partitions, you'll need to move
     at least some of the libraries in /lib to somewhere on the root
     disk, not on /usr.  Either you can go through the programs that you
     need to run at system startup or when in single-user mode, and
     identify the libraries they use, or you can depend on your
     system/distribution integrator to have done this for you and just
     move all (er ... some.  See above for the exceptions) of the
     libraries in /lib to /lib-aout.


  2.2.  Before you start --- Notes and Caveats


  o  You will need to be running a post-1.1.52 kernel with ELF binary
     format support.

  o  You are recommended to prepare or acquire a linux boot/root disk,
     such as a Slackware rescue disk.  You probably won't need it, but
     if you do and you don't have one, you'll kick yourself.  In a
     similar `prevention is better than cure' vein, statically linked
     copies of mv, ln, and maybe other file manipulation commands
     (though in fact I think you can do everything else you actually
     need to with shell builtins) may help you out of any awkward
     situations you could end up in.

  o  If you have been following the ELF development, you may have ELF
     libraries in /lib/elf (usually libc.so.4 and co).  Applications
     that you built using these should be rebuilt, then the directory
     removed.  There is no need for a /lib/elf directory!

  o  Most Linux installations these days have converged on the `FSSTND'
     standard file system, but doubtless there are still installed
     systems that haven't.  If you see references to /sbin/something and
     you don't have a /sbin directory, you'll probably find the program
     referred to in /bin or /etc/.


  2.3.  You will need ...

  The following packages are available from
  <ftp://tsx-11.mit.edu/pub/linux/packages/GCC/> and
  <ftp://sunsite.unc.edu/pub/Linux/GCC/>.  Both sites are widely
  mirrored; please take the time to look up your nearest mirror site and
  use that instead of the master sites where possible.  It's faster for
  both you and everyone else.

  These packages (either the listed version or a later one) are
  required.  Also download and read through the release notes for each
  of them: these are the files named release.packagename.  This applies
  especially if you get newer versions than are listed here, as
  procedures may have changed.

  o  ld.so-1.7.3.tar.gz --- the new dynamic linker

  o  libc-5.0.9.bin.tar.gz --- the ELF shared images for the C library
     and its friends (m (maths), termcap, gdbm, and so on), plus the
     corresponding static libraries and the include files needed to
     compile programs with them.  libc 5.2.something is expected to be
     released during the lifetime of this HOWTO, and is considerably
     different from 5.0.9; if you want to install it, you're on your
     own, but I'd recommend installing 5.0.9 first and then installing
     it over the top.  There are several parts to libc 5.0.9 which are
     not included in 5.2.x and for which the distribution channels are
     not entirely set up yet.

  o  gcc-2.7.0.bin.tar.gz --- the ELF C compiler.  Also includes an
     a.out C compiler which understands the new directory layout.

  o  binutils-2.5.2l.17.bin.tar.gz --- the GNU binary utilities patched
     for Linux.  These are programs such as gas, ld, strings and so on,
     most of which are required to make the C compiler go.


  2.4.  Rearranging your filesystem

  Sooo...  Note that in all that follows, when I say `remove' I
  naturally mean `backup then remove' :-).  Also, these instructions
  directly apply only to people who haven't yet messed with ELF ---
  those who have are expected to have the necessary nous to adapt as
  appropriate.  Let's go!


  1. Make the new directories that you will move a.out things to


       ______________________________________________________________________
       mkdir -p /usr/i486-linuxaout/bin
       mkdir -p /usr/i486-linuxaout/include
       mkdir -p /usr/i486-linuxaout/lib
       mkdir /lib-aout
       ______________________________________________________________________





  2. Untar the dynamic linker package ld.so-1.7.3 in the directory you
     usually put source code, then read through the
     ld.so-1.7.3/instldso.sh script just unpacked.  If you have a really
     standard system, run it by doing sh instldso.sh, but if you have
     anything at all unusual then do the install by hand instead.
     `Anything at all unusual' includes

  o  using zsh as a shell (some versions of zsh define $VERSION, which
     seems to confuse instldso.sh)

  o  having symlinks from /lib/elf to /lib (which you shouldn't need,
     but you may have valid reasons for if you have been following the
     ELF development)


  3. Edit /etc/ld.so.conf to add the new directory
     /usr/i486-linuxaout/lib (and /lib-aout if you're going to need
     one).  Then rerun /sbin/ldconfig -v to check that it is picking up
     the new directories.

  4. Move all the a.out libraries in /usr/*/lib to
     /usr/i486-linuxaout/lib.  Note, I said `libraries' not
     `everything'.  That's files matching the specification lib*.so* ,
     lib*.sa*, or lib*.a.  Don't start moving /usr/lib/gcc-lib or
     anything silly like that around.

  5. Now look at /lib.  Leave intact libc.so*, libm.so*, and libdl.so*.
     If you have symlinks to X libraries (libX*.so.3*) leave them there
     too --- XView and some other packages may require them.  Leave
     ld.so*, ld-linux.so* and any other files starting with ld.  As for
     the remaining libraries (if you have any left): if you have /usr on
     the root partition, put them in /usr/i486-linuxaout/lib.  If you
     have /usr mounted separately, put them in /lib-aout.  Now run
     ldconfig -v

  6. Remove the directory /usr/lib/ldscripts if it's there, in
     preparation for installing the binutils (which will recreate it)

  7. Remove any copies of ld and as (except for ld86 and as86) that you
     can find in /usr/bin.

  8. Some versions of GNU tar appear to have problems dealing with
     symbolic links in the destination directory.  You have two options
     here:


     a. (preferred) Use cpio instead of tar, it doesn't have this
        problem.  zcat /wherever/you/put/it/libc-5.0.9.tar.gz | cpio -iv
        is the magic incantation here, to be executed from the root
        directory.

     b. (if you don't have cpio installed) Before installing the libc
        images you might want to go through /usr/include and remove some
        parts.

        This is icky.  Many packages (such as ncurses) are installed
        into /usr/include by distribution maintainers and are not
        supplied with the C library.  Backup the /usr/include tree, use
        tar tzf to see what's in the archive before untarring it, then
        delete the bits of /usr/include that it actually fills.  Then
        untar the libc-5.0.9.bin.tar.gz  package from root.


  9. Install the binutils package.  tar -xvzf
     binutils-2.5.2.l17.bin.tar.gz -C /  is one perfectly good way to do
     this.

  10.
     You have now installed everything you need to run ELF executables.
     Medical experts recommend that VDU workers take regular breaks away
     from the screen; this would be an opportune moment.  Don't forget
     what you were doing, though; depending on the version of gcc you
     were previously using, you may have left yourself unable to compile
     programs in a.out until you unpack the new gcc.

  11.
     Backup and remove everything in /usr/lib/gcc-lib/{i486-linux,
     i486-linuxelf, i486-linuxaout}/  If you use a non-standard gcc
     driver (eg if you use Gnu ADA), copy that somewhere safe also.
     Then install the gcc package, again by untarring from root.

  12.
     Some programs (notably various X programs) use /lib/cpp, which
     under Linux is generally a link to /usr/lib/gcc-
     lib/i486-linux/version/cpp.  As the preceding step wiped out
     whatever version of cpp it was pointing to, you'll need to recreate
     the link:

       $ cd /lib
       $ ln -s /usr/lib/gcc-lib/i486-linux/2.7.0/cpp .





  13.
     The FSSTND people have once again justified their keep by moving
     the utmp and wtmp files from /var/adm to /var/run and /var/log
     respectively.  You'll need to add some links dependent on where
     they currently live, and you may need to make the /var/log and
     /var/adm directories too.  I reproduce below the ls -l output of
     appropriate bits on my system:



       $ ls -ld /var/adm /var/log /var/run /var/log/*tmp /var/run/*tmp
       lrwxrwxrwx   1 root     root            3 May 24 05:53 /var/adm -> log/
       drwxr-xr-x   9 root     root         1024 Aug 13 23:17 /var/log/
       lrwxrwxrwx   1 root     root           11 Aug 13 23:17 /var/log/utmp -> ../run/utmp
       -rw-r--r--   1 root     root       451472 Aug 13 23:00 /var/log/wtmp
       drwxr-xr-x   2 root     root         1024 Aug 13 23:17 /var/run/
       -rw-r--r--   1 root     root          448 Aug 13 23:00 /var/run/utmp





  Check the FSSTND (from LDP archives such as
  <ftp://sunsite.unc.edu/pub/Linux/docs/fsstnd/>) for the full story.

  14.
     This step is optional.  If you're intending to continue compiling
     programs in a.out, this is the appropriate time to install libc.so
     4.7.x.  Untar it from root, as you are now no doubt fully capable
     of doing without further explanation.

   Done!  Simple tests that you can try are



       ______________________________________________________________________
       $ gcc -v
       Reading specs from /usr/lib/gcc-lib/i486-linux/2.7.0/specs
       gcc version 2.7.0
       $ gcc -v -b i486-linuxaout
       Reading specs from /usr/lib/gcc-lib/i486-linuxaout/2.7.0/specs
       gcc version 2.7.0
       $ ld -V
       ld version cygnus/linux-2.5.2l.14 (with BFD cygnus/linux-2.5.2l.11)
         Supported emulations:
          elf_i386
          i386linux
          i386coff
       ______________________________________________________________________




  followed of course by the traditional ``Hello, world'' program.  Try
  it with gcc and with gcc -b i486-linuxaout to check that both the
  a.out and ELF compilers are set up corectly.



  2.5.  What it should look like (outline directory structure)

  This is a deliberately vague guide to what the files you have just
  installed are.  It may be useful for troubleshooting or deciding what
  to delete.


  2.5.1.
   /lib


  o  Dynamic linkers ld.so (a.out) and ld-linux.so.1 (ELF).  Either of
     these may be symlinks, but make sure that the files they point to
     do exist.

  o  Basic shared libraries libc.so.4, libm.so.4 (a.out) These are
     symlinks, but check that they point to real files.

  o  Basic shared libraries libc.so.5, libm.so.5,
     libdl.so.1,libcurses.so.1,libtermcap.so.2, (ELF).  Again, these are
     symlinks.

  o  Lots of symlinks.  For each library, there should be an actual file
     (for example libc.so.5.0.9), a symlink to it with only the major
     version number in its name (libc.so.5) and a symlink pointing to
     that with no version number (libc.so).  That's



       ______________________________________________________________________
       lrwxrwxrwx   1 root  root      9 May 24 05:52 libc.so -> libc.so.5
       lrwxrwxrwx   1 root  root     13 Aug 25 12:48 libc.so.5 -> libc.so.5.0.9
       -rwxr-xr-x   1 bin   bin  562683 May 19 04:47 libc.so.5.0.9
       ______________________________________________________________________






  2.5.2.  /usr/lib


  o  All the non-library files and directories that were there
     previously.

  o  libbfd.so*,libdb.so*, libgdbm.so*, ELF shared libraries.  All to
     consist of three files as explained above in the /lib section.

  o  libbsd.a, libgmon.a, libldso.a, libmcheck.a, libieee.a, libmcheck.a
     and one lib*.a file for every ELF shared library in /lib and
     /usr/lib .  ELF static libraries.  The ones duplicating the shared
     libraries may not be tremendously useful for most people --- when
     using ELF, you can use the gcc -g switch with shared libraries, so
     there's not much reason to compile static any longer.

  o  crt0.o, gcrt0.o.  a.out `start of program' files; one of these is
     linked as the first file in every a.out program you compile, unless
     you take steps to avoid it.

  o  crt1.o, crtbegin.o, crtbeginS.o, crtend.o, crtendS.o, crti.o,
     crtn.o, gcrt1.o.  ELF startup files.  These do similar things to
     *crt0.o above for ELF programs.



  2.5.3.
   /usr/lib/ldscripts


  o  This is where the driver scripts for ld live, as the name suggests.
     It should look like


       ______________________________________________________________________
       $ ls /usr/lib/ldscripts/
       elf_i386.x      elf_i386.xs     i386coff.xn     i386linux.xbn
       elf_i386.xbn    elf_i386.xu     i386coff.xr     i386linux.xn
       elf_i386.xn     i386coff.x      i386coff.xu     i386linux.xr
       elf_i386.xr     i386coff.xbn    i386linux.x     i386linux.xu
       ______________________________________________________________________





  2.5.4.  /usr/i486-linux/bin


  o  ar, as, gasp, ld, nm, ranlib, strip.  These are all actually
     symlinks to the real binutils in /usr/bin


  2.5.5.  /usr/i486-linuxaout/bin


  o  as --- the a.out assembler, and gasp, its macro preprocessor

  o  ar, ld, nm, ranlib, strip --- symlinks to the real binutils in
     /usr/bin


  2.5.6.  /usr/i486-linux/lib


  o  ldscripts is a symlink to /usr/lib/ldscripts.


  2.5.7.  /usr/i486-linuxaout/lib


  o  lib*.so*. a.out shared library images.  Needed to run a.out
     programs

  o  lib*.sa. a.out shared library stubs.  Needed to compile a.out
     programs that use shared libraries.  If you don't intend to, you
     can safely remove these.

  o  lib*.a. a.out static libraries.  Needed to compile static a.out
     programs (eg when compiling with -g).  Again, you can delete them
     if you don't intend to.

  o  ldscripts is a symbolic link to /usr/lib/ldscripts


  2.5.8.  /usr/lib/gcc-lib/i486-linux/2.7.0


  o  This directory contains a version of gcc 2.7.0 set up to compile
     ELF programs.


  2.5.9.  /usr/lib/gcc-lib/i486-linuxaout/2.7.0


  o  This directory contains a version of gcc 2.7.0 set up to compile
     a.out programs, which knows about the new directory structure.  If
     you're not going to compile anything in a.out, deleting this may
     free up around 4Mb.


  2.6.  Common errors (Don't Panic!)




      You moved the wrong thing and now nothing runs
        You still have a shell running, though, and with a little
        ingenuity you can do an awful lot with shell builtins.  Remember
        that echo * is an acceptable substitute for ls, and echo
        >>filename can be used to add lines to a file.  Also, don't
        forget that ldconfig is linked static.  If you moved, say,
        libc.so.4 to /lib-aout mistakenly, you can do echo "lib-aout"
        >>/etc/ld.so.conf ; ldconfig -v/ and be back up again.  If you
        moved /lib/ld.so you may be able to do sln /silly/place/ld.so
        /lib/ld.so, if you have a statically linked ln, and probably be
        back up again.


      no such file or directory: /usr/bin/gcc
        that the ELF dynamic loader /lib/ld-linux.so.1 is not installed,
        or is unreadable for some reason.  You should have installed it
        at around step 2 previously.


      not a ZMAGIC file, skipping
        from ldconfig.  You have an old version of the ld.so package, so
        get a recent one.  Again, see step 2 of the installation.


      bad address
        on attempting to run anything ELF.  You're using kernel 1.3.x,
        where x<3.  Upgrade to 1.3.3 or downgrade to 1.2.something


      _setutent: Can't open utmp file
        This message is often seen in multiples of three when you start
        an xterm.  Go and read the FSSTND tirade near the end of the
        installation procedure.


      gcc: installation problem, cannot exec something: No such file or
        directory
        when attempting to do a.out compilations (something is usually
        one of cpp or cc1).  Either it's right, or alternatively you
        typed



          $ gcc -b -i486-linuxaout




     when you should have typed



     $ gcc -b i486-linuxaout




     Note that the `i486' does not start with a dash.



  3.  Building programs in ELF

  3.1.  Ordinary programs

  To build a program in ELF, use gcc as always.  To build in a.out, use
  gcc -b i486-linuxaout .



       ______________________________________________________________________
       $ cat >hello.c
       main() { printf("hello, world\n"); }
       ^D
       $ gcc -o hello hello.c
       $ file hello
       hello: ELF 32-bit LSB executable i386 (386 and up) Version 1
       $ ./hello
       hello, world
       ______________________________________________________________________




  This is perhaps an appropriate time to answer the question ``if a.out
  compilers default to producing a program called a.out, what name does
  an ELF compiler give its output?''.  Still a.out, is the answer.
  Boring boring boring ...  :-)


  3.2.  Building libraries

  To build libfoo.so as a shared library, the basic steps look like
  this:



       ______________________________________________________________________
       $ gcc -fPIC -c *.c
       $ gcc -shared -Wl,-soname,libfoo.so.1 -o libfoo.so.1.0 *.o
       $ ln -s libfoo.so.1.0 libfoo.so.1
       $ ln -s libfoo.so.1 libfoo.so
       $ export LD_LIBRARY_PATH=`pwd`:$LD_LIBRARY_PATH
       ______________________________________________________________________




  This will generate a shared library called libfoo.so.1.0, and the
  appropriate links for ld (libfoo.so) and the dynamic linker
  (libfoo.so.1) to find it.  To test, we add the current directory to
  LD_LIBRARY_PATH.

  When you're happpy that the library works, you'll have to move it to,
  say, /usr/local/lib, and recreate the appropriate links.  Note that
  the libfoo.so link should point to libfoo.so.1, so it doesn't need
  updating on every minor version number change.  The link from
  libfoo.so.1 to libfoo.so.1.0 is kept up to date by ldconfig, which on
  most systems is run as part of the boot process.



       ______________________________________________________________________
       $ su
       # cp libfoo.so.1.0 /usr/local/lib
       # /sbin/ldconfig
       # ( cd /usr/local/lib ; ln -s libfoo.so.1 libfoo.so )
       ______________________________________________________________________





  3.3.  Programs with dynamic loading

  These are covered extensively in H J Lu's ELF programming document,
  and the dlopen(3) manual page, which can be found in the ld.so
  package.  Here's a nice simple example though: link it with -ldl



       ______________________________________________________________________
       #include <dlfcn.h>
       #include <stdio.h>

       main()
       {
         void *libc;
         void (*printf_call)();

         if(libc=dlopen("/lib/libc.so.5",RTLD_LAZY))
         {
           printf_call=dlsym(libc,"printf");
           (*printf_call)("hello, world\n");
         }

       }
       ______________________________________________________________________





  3.4.  Debugging

  Your existing copy of gdb will most likely work unchanged with ELF
  programs.  The new version in the GCC directory on tsx-11 is reported
  to be better at debugging programs that use shared libraries and
  dynamic loading, and to understand ELF core dumps.

  Note that 1.2 series kernels cannot generate core dumps from ELF
  programs anyway.  1.3 can.


  4.  Patches and binaries

  At this point in the proceedings, you can, if you like, stop.  You
  have installed everything necessary to compile and run ELF programs.

  You may wish to rebuild some programs in ELF, either for purposes of
  `neatness' or to minimise memory usage.  For most end-user
  applications, this is pretty simple; some packages however do assume
  too much about the systems they run on, and may fail due to one or
  more of:
  o  Different underscore conventions in the assembler: in an a.out
     executable, external labels get _ prefixed to them; in an ELF
     executable, they don't.  This makes no difference until you start
     integrating hand-written assembler: all the labels of the form _foo
     must be translated to foo, or (if you want to be portable about it)
     to EXTERNAL(foo) where EXTERNAL is some macro which returns either
     its argument (if __ELF__ is defined) or _ concatenated with its
     argument if not.

  o  Differences in libc 5 from libc 4.  The interface to the locale
     support has changed, for one.

  o  The application or build process depending on knowledge of the
     binary format used --- emacs, for example, dumps its memory image
     to disk in executable format, so obviously needs to know what
     format your executables are in.

  o  The application consists of or includes shared libraries (X11 is
     the obvious example).  These will obviously need changes to
     accomodate the different method of shared library creation in ELF.

  Anyway, here are two lists: the first is of programs that needed
  changing for ELF where the changes have been made (ie that you will
  need new versions of to compile as ELF), and the second is of programs
  that still need third-party patches of some kind.


  4.1.  Upgrade:


  o  Dosemu.  Modulo the three or four cuurrent dosemu development trees
     (don't ask, just join the linux-msdos mailing list), dosemu runs
     with ELF.  You'll need to monkey with the Makefile.  Current
     versions of dosemu are available from
     <ftp://tsx-11.mit.edu/pub/linux/ALPHA/dosemu/>

  o  Emacs.  Emacs has a rather odd build procedure that involves
     running a minimal version of itself, loading in all the useful bits
     as lisp, then dumping its memory image back to disk as an
     executable file.  (FSF) Emacs 19.29 and XEmacs 19.12 (formerly
     Lucid Emacs) can both detect whether you are compiling as ELF and
     Do The Right Thing automatically.

  o  MAKEDEV.  In some incarnations, this utility removes existing
     entries for devices before recreating them.  This is Bad News if it
     happens to touch /dev/zero, as said device is necessary to the
     operation of all ELF programs.  See the util-linux package(q.v.)
     for a fixed version.

  o  perl 5.001.  Perl 5.001 plus the ``official unofficial'' patches a-
     e will compile unchanged on an ELF system, complete with dynamic
     loading.  The patches are available from ftp.metronet.com or
     ftp.wpi.edu

  o  The cal program in util-linux 2.2 doesn't work.  Upgrade to version
     2.4 <ftp://tsx-11.mit.edu/pub/linux/packages/utils> or later.

  o  XFree86.  XFree86 3.1.2 comes in both a.out and ELF formats.  ftp
     to ftp.xfree86.org, read the `too many users' message that you are
     almost guaranteed to get, and pick the closest mirror site network-
     wise to you.  Once you have the contents of the common and elf
     directories, you must edit /usr/X11R6/lib/X11/config/linux.cf to
     change the lines saying



  #define LinuxElfDefault         NO
  #define UseElfFormat            NO





  to say YES instead.  Otherwise an xpm build will attempt to do odd
  stuff with jumpas and its associated relics of the past.

  o  Mosaic.  I don't have the facilities to build this myself, but the
     Mosaic 2.7b1 binary available from NCSA comes in ELF.  It has been
     linked against an odd X setup though, with the result that on
     normal systems it will complain about not finding libXpm.so.4.5.
     The simple fix is to edit it carefully with emacs or another editor
     that copes with binary files.  Find the occurence of the string
     libXpm.so.4.5^@ (where ^@ is a NUL --- ASCII zero --- character),
     delete the .5 and add two more characters after the NUL to aviod
     changing the file length.


  4.2.  Patch


  o  e2fsutils.  The Utilities for the Second Extended File System need
     a patch from
     <ftp://ftp.ibp.fr/pub/linux/ELF/patches/e2fsprogs-0.5b.elf.diff.gz>
     to compile correctly as a shared library.  Remy Card says ``This is
     the ELF patch which will probably be included in the next release
     of e2fsck and co''

  o  file.  This works anyway, but can be improved:
     <http://sable.ox.ac.uk/~jo95004/patches/file.diff> adds support for
     identifying stripped and mixed-endian ELF binaries.

  o  The Kernel.  As from at least 1.3.8, the development 1.3 series
     have a make config option to build using ELF tools.  If you are
     using the 1.2 series, you have two options:


     1. Patch the Makefile slightly to use the a.out compiler.  Just
        change the CC and LD definitions to be



          ___________________________________________________________________
          LD      =ld -m i386linux
          CC      =gcc -b i486-linuxaout -D__KERNEL__ -I$(TOPDIR)/include
          ___________________________________________________________________





     Alternatively,

     2. Apply H J Lu's patch which allows compiling the kernel in ELF
        (and also adds the ability to do ELF core dumps).


     Let me reiterate that neither of these is necessary for the 1.3
     series.

  o  ps (procps-0.97) The psupdate program needs a patch to work if you
     have compiled the kernel as ELF.  It's available in
     <linux.nrao.edu:/pub/people/juphoff/procps>, both as a patch to
     vanilla 0.97 and as an entire tar-file.  A new version of procps is
     expected to be released soon with this patch in place, so if you
     can find procps 0.98 by the time you read this, this patch will
     probably be obsolete.


  5.  Further information



  o  The linux-gcc mailing list is really the best place to see what's
     happening, usually without even posting to it.  Remember, it's not
     Usenet, so keep the questions down unless you're actually
     developing.  For instructions on joining the mailing list, mail a
     message containing the word help to majo...@vger.rutgers.edu.
     Archives of the list are at  <http://homer.ncm.com/>.

  o  There's a certain amount of information about what the linux-gcc
     list is doing at my ELF web page
     <http://sable.ox.ac.uk/~jo95004/elf.html>, when I remember to
     update it.  This also has a link to the latest version of this
     HOWTO, and the patches it refers to.  For US people and others with
     poor links to UK academic sites (that's nearly everyone outside of
     UK academia), this is all mirrored at
     <http://www.blackdown.org/elf/elf.html>

  o  See also Bobby Shmit's ELF upgrade experience
     <http://www.intac.com/~cully/elf.html> web page.

  o  The GCC-FAQ <ftp://sunsite.unc.edu/pub/Linux/docs/faqs/GCC-
     FAQ.html> contains much general development information and some
     more technical ELF details.

  o  There's also documentation for the file format on tsx-11
     <ftp://tsx-11.mit.edu/pub/linux/packages/GCC/ELF.doc.tar.gz>.  This
     is probably of most use to people who want to understand, debug or
     rewrite programs that deal directly with binary objects.

  o  H J Lu's document ELF: From The Programmer's Perspective
     <ftp://tsx-11.mit.edu/pub/linux/packages/GCC/elf.latex.tar.gz>
     contains much useful and more detailed information on programming
     with ELF.  If you aren't LaTeX-capable, it is also available as
     PostScript.

  o  There is a manual page for dlopen(3) supplied with the ld.so
     package.


  6.  Legalese

  All trademarks used in this document are acknowledged as being owned
  by their respective owners.  (Spot the teeth-gritting irony there...)


  The right of Daniel Barlow to be identified as the author of this work
  has been asserted in accordance with sections 77 and 78 of the
  Copyright Designs and Patents Act 1988.  (Proof by assertion

  This document is copyright (C) 1995 Daniel Barlow
  <daniel...@sjc.ox.ac.uk> It may be reproduced and distributed in
  whole or in part, in any medium physical or electronic, as long as
  this copyright notice is retained on all copies. Commercial
  redistribution is allowed and encouraged; however, the author would
  like to be notified of any such distributions.


  All translations, derivative works, or aggregate works incorporating
  any Linux HOWTO documents must be covered under this copyright notice.
  That is, you may not produce a derivative work from a HOWTO and impose
  additional restrictions on its distribution. Exceptions to these rules
  may be granted under certain conditions; please contact the Linux
  HOWTO coordinator at the address given below.

  In short, we wish to promote dissemination of this information through
  as many channels as possible. However, we do wish to retain copyright
  on the HOWTO documents, and would like to be notified of any plans to
  redistribute the HOWTOs.

  If you have questions, please contact Greg Hankins, the Linux HOWTO
  coordinator, at gr...@sunsite.unc.edu via email, or at +1 404 853
  9989.

- --- END Linux ELF HOWTO part 1/1 ---

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: finger gr...@cc.gatech.edu for public key

iQCVAwUBMJjt3HtNTo2suu5NAQHVGwP+MPTphafw7sflUWrW8usAUIea7r/CMrsb
+L0Ol5dy50CRtb91qqW+avxDtaL7866gK/rs+BUNZMGRXMXu5h2LmgIqKPKTHG4x
I3kCUFoOIZn1M/vbYL+vgxWH8+9tvmCBf7Zu8HL+zRtZbhq5xilE+BOWmjERUiDP
02gLE4lZcA0=
=CrpD
-----END PGP SIGNATURE-----

From: Daniel Barlow <daniel...@sjc.ox.ac.uk>
Subject: Linux ELF HOWTO (part 1/1)
Date: 1995/11/30
Message-ID: <ELF-HOWTO.1-7368.817769616@cc.gatech.edu>
X-Deja-AN: 120595380
sender: gr...@cc.gatech.edu
followup-to: poster
summary: How to install and migrate to the ELF binary file format
organization: Linux HOWTO Project
keywords: Linux, HOWTO, ELF
newsgroups: comp.os.linux.answers,comp.os.linux.development.system,comp.os.linux.setup
nntp-posting-user: gregh

Archive-Name: linux/howto/elf
Last-modified: 15 Sep 95

-----BEGIN PGP SIGNED MESSAGE-----

*** The `Linux ELF HOWTO' is posted automatically by the
*** Linux HOWTO coordinator, Greg Hankins <gr...@sunsite.unc.edu>.  Please
*** direct any comments or questions about this HOWTO to the author,
*** Daniel Barlow <daniel...@sjc.ox.ac.uk>.

- --- BEGIN Linux ELF HOWTO part 1/1 ---

  The Linux ELF HOWTO
  Daniel Barlow <daniel...@sjc.ox.ac.uk>
  v1.11, 13 September 1995

  This document describes how to migrate your Linux system to compile
  and run programs in the ELF binary format.  It falls into three con-
  ceptual parts: (1) What ELF is, and why/whether you should upgrade,
  (2) How to upgrade to ELF-capability, and (3) what you can do then.

  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:


  o  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 com-
  piling 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).

  o  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?


  2.  Installation

  2.1.  Background

  The aim of this conversion is to leave you with a system which can
  build and run both a.out and ELF programs, with each type of program
  being able to find its appropriate breed of shared libraries.  This
  obviously requires a bit more intelligence in the library search
  routines than the simple `look in /lib, /usr/lib and anywhere else
  that the program was compiled to search' strategy that some other
  systems can get away with.

  The beastie responsible for searching out libraries in linux is
  /lib/ld.so.  The compiler and linker do not encode absolute library
  pathnames into the programs they output; instead they put the library
  name and the absolute path to ld.so in, and leave ld.so to match the
  library name to the appropriate place at runtime.  This has one very
  important effect --- it means that the libraries that a program uses
  can be moved to other directories without recompiling the program,
  provided that ld.so is told to search the new directory.  This is
  essential functionality for the directory swapping operation that
  follows.

  The corollary of the above, of course, is that any attempt to delete
  or move ld.so will cause every dynamically linked program on the
  system to stop working.  This is generally regarded as a Bad Thing.

  For ELF binaries, an alternate dynamic loader is provided.  This is
   /lib/ld-linux.so.1, and does exactly the same thing as ld.so, but for
  ELF programs.  ld-linux.so.1 uses the same support files and programs
  (ldd, ldconfig, and /etc/ld.so.conf) as the a.out loader ld.so does.

  The basic plan, then, is that ELF development things (compilers,
  include files and libraries) go into /usr/{bin,lib,include} where your
  a.out ones currently are, and the a.out things will be moved into
  /usr/i486-linuxaout/{bin, lib, include}.  /etc/ld.so.conf lists all
  the places on the system where libraries are expected to be found, and
  ldconfig is intelligent enough to distinguish between ELF and a.out
  variants.

  There are a couple of exceptions to the library placement, though.

  o  Some old programs were built without the use of ld.so.  These would
     all cease working if their libraries were moved from under them.
     Thus, libc.so* and libm.so* must stay where they are in /lib, and
     the ELF versions have had their major numbers upgraded so that they
     do not overwrite the a.out ones.  Old X libraries (prior to version
     6) are best left where they are also, although newer ones
     (libX*so.6) must be moved.  Moving the old ones will apparently
     break xview programs, and not moving the new ones will cause them
     to be overwritten when you install ELF X libraries.

     If you have non-ld.so programs that require libraries other than
     the above (if you know which programs they are, you can run ldd on
     them to find out which libraries they need before breaking them)
     you have essentially two options.  One, you can extract the ELF
     library tar files into a temporary directory, check whether your
     precious library would be overwritten, and if so, move the ELF
     version of the library into, say, /usr/i486-linux/lib instead of
     /lib.  Make sure your ld.so.conf has /usr/i486-linux/lib in it,
     then run ldconfig and think no more on't.  Two, you can recompile
     or acquire a newer copy of the offending program.  This might not
     be a bad idea, if possible.

  o  If you have /usr and / on different partitions, you'll need to move
     at least some of the libraries in /lib to somewhere on the root
     disk, not on /usr.  Either you can go through the programs that you
     need to run at system startup or when in single-user mode, and
     identify the libraries they use, or you can depend on your
     system/distribution integrator to have done this for you and just
     move all (er ... some.  See above for the exceptions) of the
     libraries in /lib to /lib-aout.


  2.2.  Before you start --- Notes and Caveats


  o  You will need to be running a post-1.1.52 kernel with ELF binary
     format support.

  o  You are recommended to prepare or acquire a linux boot/root disk,
     such as a Slackware rescue disk.  You probably won't need it, but
     if you do and you don't have one, you'll kick yourself.  In a
     similar `prevention is better than cure' vein, statically linked
     copies of mv, ln, and maybe other file manipulation commands
     (though in fact I think you can do everything else you actually
     need to with shell builtins) may help you out of any awkward
     situations you could end up in.

  o  If you have been following the ELF development, you may have ELF
     libraries in /lib/elf (usually libc.so.4 and co).  Applications
     that you built using these should be rebuilt, then the directory
     removed.  There is no need for a /lib/elf directory!

  o  Most Linux installations these days have converged on the `FSSTND'
     standard file system, but doubtless there are still installed
     systems that haven't.  If you see references to /sbin/something and
     you don't have a /sbin directory, you'll probably find the program
     referred to in /bin or /etc/.


  2.3.  You will need ...

  The following packages are available from
  <ftp://tsx-11.mit.edu/pub/linux/packages/GCC/> and
  <ftp://sunsite.unc.edu/pub/Linux/GCC/>.  Both sites are widely
  mirrored; please take the time to look up your nearest mirror site and
  use that instead of the master sites where possible.  It's faster for
  both you and everyone else.

  These packages (either the listed version or a later one) are
  required.  Also download and read through the release notes for each
  of them: these are the files named release.packagename.  This applies
  especially if you get newer versions than are listed here, as
  procedures may have changed.

  o  ld.so-1.7.3.tar.gz --- the new dynamic linker

  o  libc-5.0.9.bin.tar.gz --- the ELF shared images for the C library
     and its friends (m (maths), termcap, gdbm, and so on), plus the
     corresponding static libraries and the include files needed to
     compile programs with them.  libc 5.2.something is expected to be
     released during the lifetime of this HOWTO, and is considerably
     different from 5.0.9; if you want to install it, you're on your
     own, but I'd recommend installing 5.0.9 first and then installing
     it over the top.  There are several parts to libc 5.0.9 which are
     not included in 5.2.x and for which the distribution channels are
     not entirely set up yet.

  o  gcc-2.7.0.bin.tar.gz --- the ELF C compiler.  Also includes an
     a.out C compiler which understands the new directory layout.

  o  binutils-2.5.2l.17.bin.tar.gz --- the GNU binary utilities patched
     for Linux.  These are programs such as gas, ld, strings and so on,
     most of which are required to make the C compiler go.


  2.4.  Rearranging your filesystem

  Sooo...  Note that in all that follows, when I say `remove' I
  naturally mean `backup then remove' :-).  Also, these instructions
  directly apply only to people who haven't yet messed with ELF ---
  those who have are expected to have the necessary nous to adapt as
  appropriate.  Let's go!


  1. Make the new directories that you will move a.out things to


       ______________________________________________________________________
       mkdir -p /usr/i486-linuxaout/bin
       mkdir -p /usr/i486-linuxaout/include
       mkdir -p /usr/i486-linuxaout/lib
       mkdir /lib-aout
       ______________________________________________________________________





  2. Untar the dynamic linker package ld.so-1.7.3 in the directory you
     usually put source code, then read through the
     ld.so-1.7.3/instldso.sh script just unpacked.  If you have a really
     standard system, run it by doing sh instldso.sh, but if you have
     anything at all unusual then do the install by hand instead.
     `Anything at all unusual' includes

  o  using zsh as a shell (some versions of zsh define $VERSION, which
     seems to confuse instldso.sh)

  o  having symlinks from /lib/elf to /lib (which you shouldn't need,
     but you may have valid reasons for if you have been following the
     ELF development)


  3. Edit /etc/ld.so.conf to add the new directory
     /usr/i486-linuxaout/lib (and /lib-aout if you're going to need
     one).  Then rerun /sbin/ldconfig -v to check that it is picking up
     the new directories.

  4. Move all the a.out libraries in /usr/*/lib to
     /usr/i486-linuxaout/lib.  Note, I said `libraries' not
     `everything'.  That's files matching the specification lib*.so* ,
     lib*.sa*, or lib*.a.  Don't start moving /usr/lib/gcc-lib or
     anything silly like that around.

  5. Now look at /lib.  Leave intact libc.so*, libm.so*, and libdl.so*.
     If you have symlinks to X libraries (libX*.so.3*) leave them there
     too --- XView and some other packages may require them.  Leave
     ld.so*, ld-linux.so* and any other files starting with ld.  As for
     the remaining libraries (if you have any left): if you have /usr on
     the root partition, put them in /usr/i486-linuxaout/lib.  If you
     have /usr mounted separately, put them in /lib-aout.  Now run
     ldconfig -v

  6. Remove the directory /usr/lib/ldscripts if it's there, in
     preparation for installing the binutils (which will recreate it)

  7. Remove any copies of ld and as (except for ld86 and as86) that you
     can find in /usr/bin.

  8. Some versions of GNU tar appear to have problems dealing with
     symbolic links in the destination directory.  You have two options
     here:


     a. (preferred) Use cpio instead of tar, it doesn't have this
        problem.  zcat /wherever/you/put/it/libc-5.0.9.tar.gz | cpio -iv
        is the magic incantation here, to be executed from the root
        directory.

     b. (if you don't have cpio installed) Before installing the libc
        images you might want to go through /usr/include and remove some
        parts.

        This is icky.  Many packages (such as ncurses) are installed
        into /usr/include by distribution maintainers and are not
        supplied with the C library.  Backup the /usr/include tree, use
        tar tzf to see what's in the archive before untarring it, then
        delete the bits of /usr/include that it actually fills.  Then
        untar the libc-5.0.9.bin.tar.gz  package from root.


  9. Install the binutils package.  tar -xvzf
     binutils-2.5.2.l17.bin.tar.gz -C /  is one perfectly good way to do
     this.

  10.
     You have now installed everything you need to run ELF executables.
     Medical experts recommend that VDU workers take regular breaks away
     from the screen; this would be an opportune moment.  Don't forget
     what you were doing, though; depending on the version of gcc you
     were previously using, you may have left yourself unable to compile
     programs in a.out until you unpack the new gcc.

  11.
     Backup and remove everything in /usr/lib/gcc-lib/{i486-linux,
     i486-linuxelf, i486-linuxaout}/  If you use a non-standard gcc
     driver (eg if you use Gnu ADA), copy that somewhere safe also.
     Then install the gcc package, again by untarring from root.

  12.
     Some programs (notably various X programs) use /lib/cpp, which
     under Linux is generally a link to /usr/lib/gcc-
     lib/i486-linux/version/cpp.  As the preceding step wiped out
     whatever version of cpp it was pointing to, you'll need to recreate
     the link:

       $ cd /lib
       $ ln -s /usr/lib/gcc-lib/i486-linux/2.7.0/cpp .





  13.
     The FSSTND people have once again justified their keep by moving
     the utmp and wtmp files from /var/adm to /var/run and /var/log
     respectively.  You'll need to add some links dependent on where
     they currently live, and you may need to make the /var/log and
     /var/adm directories too.  I reproduce below the ls -l output of
     appropriate bits on my system:



       $ ls -ld /var/adm /var/log /var/run /var/log/*tmp /var/run/*tmp
       lrwxrwxrwx   1 root     root            3 May 24 05:53 /var/adm -> log/
       drwxr-xr-x   9 root     root         1024 Aug 13 23:17 /var/log/
       lrwxrwxrwx   1 root     root           11 Aug 13 23:17 /var/log/utmp -> ../run/utmp
       -rw-r--r--   1 root     root       451472 Aug 13 23:00 /var/log/wtmp
       drwxr-xr-x   2 root     root         1024 Aug 13 23:17 /var/run/
       -rw-r--r--   1 root     root          448 Aug 13 23:00 /var/run/utmp





  Check the FSSTND (from LDP archives such as
  <ftp://sunsite.unc.edu/pub/Linux/docs/fsstnd/>) for the full story.

  14.
     This step is optional.  If you're intending to continue compiling
     programs in a.out, this is the appropriate time to install libc.so
     4.7.x.  Untar it from root, as you are now no doubt fully capable
     of doing without further explanation.

   Done!  Simple tests that you can try are



       ______________________________________________________________________
       $ gcc -v
       Reading specs from /usr/lib/gcc-lib/i486-linux/2.7.0/specs
       gcc version 2.7.0
       $ gcc -v -b i486-linuxaout
       Reading specs from /usr/lib/gcc-lib/i486-linuxaout/2.7.0/specs
       gcc version 2.7.0
       $ ld -V
       ld version cygnus/linux-2.5.2l.14 (with BFD cygnus/linux-2.5.2l.11)
         Supported emulations:
          elf_i386
          i386linux
          i386coff
       ______________________________________________________________________




  followed of course by the traditional ``Hello, world'' program.  Try
  it with gcc and with gcc -b i486-linuxaout to check that both the
  a.out and ELF compilers are set up corectly.



  2.5.  What it should look like (outline directory structure)

  This is a deliberately vague guide to what the files you have just
  installed are.  It may be useful for troubleshooting or deciding what
  to delete.


  2.5.1.
   /lib


  o  Dynamic linkers ld.so (a.out) and ld-linux.so.1 (ELF).  Either of
     these may be symlinks, but make sure that the files they point to
     do exist.

  o  Basic shared libraries libc.so.4, libm.so.4 (a.out) These are
     symlinks, but check that they point to real files.

  o  Basic shared libraries libc.so.5, libm.so.5,
     libdl.so.1,libcurses.so.1,libtermcap.so.2, (ELF).  Again, these are
     symlinks.

  o  Lots of symlinks.  For each library, there should be an actual file
     (for example libc.so.5.0.9), a symlink to it with only the major
     version number in its name (libc.so.5) and a symlink pointing to
     that with no version number (libc.so).  That's



       ______________________________________________________________________
       lrwxrwxrwx   1 root  root      9 May 24 05:52 libc.so -> libc.so.5
       lrwxrwxrwx   1 root  root     13 Aug 25 12:48 libc.so.5 -> libc.so.5.0.9
       -rwxr-xr-x   1 bin   bin  562683 May 19 04:47 libc.so.5.0.9
       ______________________________________________________________________






  2.5.2.  /usr/lib


  o  All the non-library files and directories that were there
     previously.

  o  libbfd.so*,libdb.so*, libgdbm.so*, ELF shared libraries.  All to
     consist of three files as explained above in the /lib section.

  o  libbsd.a, libgmon.a, libldso.a, libmcheck.a, libieee.a, libmcheck.a
     and one lib*.a file for every ELF shared library in /lib and
     /usr/lib .  ELF static libraries.  The ones duplicating the shared
     libraries may not be tremendously useful for most people --- when
     using ELF, you can use the gcc -g switch with shared libraries, so
     there's not much reason to compile static any longer.

  o  crt0.o, gcrt0.o.  a.out `start of program' files; one of these is
     linked as the first file in every a.out program you compile, unless
     you take steps to avoid it.

  o  crt1.o, crtbegin.o, crtbeginS.o, crtend.o, crtendS.o, crti.o,
     crtn.o, gcrt1.o.  ELF startup files.  These do similar things to
     *crt0.o above for ELF programs.



  2.5.3.
   /usr/lib/ldscripts


  o  This is where the driver scripts for ld live, as the name suggests.
     It should look like


       ______________________________________________________________________
       $ ls /usr/lib/ldscripts/
       elf_i386.x      elf_i386.xs     i386coff.xn     i386linux.xbn
       elf_i386.xbn    elf_i386.xu     i386coff.xr     i386linux.xn
       elf_i386.xn     i386coff.x      i386coff.xu     i386linux.xr
       elf_i386.xr     i386coff.xbn    i386linux.x     i386linux.xu
       ______________________________________________________________________





  2.5.4.  /usr/i486-linux/bin


  o  ar, as, gasp, ld, nm, ranlib, strip.  These are all actually
     symlinks to the real binutils in /usr/bin


  2.5.5.  /usr/i486-linuxaout/bin


  o  as --- the a.out assembler, and gasp, its macro preprocessor

  o  ar, ld, nm, ranlib, strip --- symlinks to the real binutils in
     /usr/bin


  2.5.6.  /usr/i486-linux/lib


  o  ldscripts is a symlink to /usr/lib/ldscripts.


  2.5.7.  /usr/i486-linuxaout/lib


  o  lib*.so*. a.out shared library images.  Needed to run a.out
     programs

  o  lib*.sa. a.out shared library stubs.  Needed to compile a.out
     programs that use shared libraries.  If you don't intend to, you
     can safely remove these.

  o  lib*.a. a.out static libraries.  Needed to compile static a.out
     programs (eg when compiling with -g).  Again, you can delete them
     if you don't intend to.

  o  ldscripts is a symbolic link to /usr/lib/ldscripts


  2.5.8.  /usr/lib/gcc-lib/i486-linux/2.7.0


  o  This directory contains a version of gcc 2.7.0 set up to compile
     ELF programs.


  2.5.9.  /usr/lib/gcc-lib/i486-linuxaout/2.7.0


  o  This directory contains a version of gcc 2.7.0 set up to compile
     a.out programs, which knows about the new directory structure.  If
     you're not going to compile anything in a.out, deleting this may
     free up around 4Mb.


  2.6.  Common errors (Don't Panic!)




      You moved the wrong thing and now nothing runs
        You still have a shell running, though, and with a little
        ingenuity you can do an awful lot with shell builtins.  Remember
        that echo * is an acceptable substitute for ls, and echo
        >>filename can be used to add lines to a file.  Also, don't
        forget that ldconfig is linked static.  If you moved, say,
        libc.so.4 to /lib-aout mistakenly, you can do echo "lib-aout"
        >>/etc/ld.so.conf ; ldconfig -v/ and be back up again.  If you
        moved /lib/ld.so you may be able to do sln /silly/place/ld.so
        /lib/ld.so, if you have a statically linked ln, and probably be
        back up again.


      no such file or directory: /usr/bin/gcc
        that the ELF dynamic loader /lib/ld-linux.so.1 is not installed,
        or is unreadable for some reason.  You should have installed it
        at around step 2 previously.


      not a ZMAGIC file, skipping
        from ldconfig.  You have an old version of the ld.so package, so
        get a recent one.  Again, see step 2 of the installation.


      bad address
        on attempting to run anything ELF.  You're using kernel 1.3.x,
        where x<3.  Upgrade to 1.3.3 or downgrade to 1.2.something


      _setutent: Can't open utmp file
        This message is often seen in multiples of three when you start
        an xterm.  Go and read the FSSTND tirade near the end of the
        installation procedure.


      gcc: installation problem, cannot exec something: No such file or
        directory
        when attempting to do a.out compilations (something is usually
        one of cpp or cc1).  Either it's right, or alternatively you
        typed



          $ gcc -b -i486-linuxaout




     when you should have typed



     $ gcc -b i486-linuxaout




     Note that the `i486' does not start with a dash.



  3.  Building programs in ELF

  3.1.  Ordinary programs

  To build a program in ELF, use gcc as always.  To build in a.out, use
  gcc -b i486-linuxaout .



       ______________________________________________________________________
       $ cat >hello.c
       main() { printf("hello, world\n"); }
       ^D
       $ gcc -o hello hello.c
       $ file hello
       hello: ELF 32-bit LSB executable i386 (386 and up) Version 1
       $ ./hello
       hello, world
       ______________________________________________________________________




  This is perhaps an appropriate time to answer the question ``if a.out
  compilers default to producing a program called a.out, what name does
  an ELF compiler give its output?''.  Still a.out, is the answer.
  Boring boring boring ...  :-)


  3.2.  Building libraries

  To build libfoo.so as a shared library, the basic steps look like
  this:



       ______________________________________________________________________
       $ gcc -fPIC -c *.c
       $ gcc -shared -Wl,-soname,libfoo.so.1 -o libfoo.so.1.0 *.o
       $ ln -s libfoo.so.1.0 libfoo.so.1
       $ ln -s libfoo.so.1 libfoo.so
       $ export LD_LIBRARY_PATH=`pwd`:$LD_LIBRARY_PATH
       ______________________________________________________________________




  This will generate a shared library called libfoo.so.1.0, and the
  appropriate links for ld (libfoo.so) and the dynamic linker
  (libfoo.so.1) to find it.  To test, we add the current directory to
  LD_LIBRARY_PATH.

  When you're happpy that the library works, you'll have to move it to,
  say, /usr/local/lib, and recreate the appropriate links.  Note that
  the libfoo.so link should point to libfoo.so.1, so it doesn't need
  updating on every minor version number change.  The link from
  libfoo.so.1 to libfoo.so.1.0 is kept up to date by ldconfig, which on
  most systems is run as part of the boot process.



       ______________________________________________________________________
       $ su
       # cp libfoo.so.1.0 /usr/local/lib
       # /sbin/ldconfig
       # ( cd /usr/local/lib ; ln -s libfoo.so.1 libfoo.so )
       ______________________________________________________________________





  3.3.  Programs with dynamic loading

  These are covered extensively in H J Lu's ELF programming document,
  and the dlopen(3) manual page, which can be found in the ld.so
  package.  Here's a nice simple example though: link it with -ldl



       ______________________________________________________________________
       #include <dlfcn.h>
       #include <stdio.h>

       main()
       {
         void *libc;
         void (*printf_call)();

         if(libc=dlopen("/lib/libc.so.5",RTLD_LAZY))
         {
           printf_call=dlsym(libc,"printf");
           (*printf_call)("hello, world\n");
         }

       }
       ______________________________________________________________________





  3.4.  Debugging

  Your existing copy of gdb will most likely work unchanged with ELF
  programs.  The new version in the GCC directory on tsx-11 is reported
  to be better at debugging programs that use shared libraries and
  dynamic loading, and to understand ELF core dumps.

  Note that 1.2 series kernels cannot generate core dumps from ELF
  programs anyway.  1.3 can.


  4.  Patches and binaries

  At this point in the proceedings, you can, if you like, stop.  You
  have installed everything necessary to compile and run ELF programs.

  You may wish to rebuild some programs in ELF, either for purposes of
  `neatness' or to minimise memory usage.  For most end-user
  applications, this is pretty simple; some packages however do assume
  too much about the systems they run on, and may fail due to one or
  more of:
  o  Different underscore conventions in the assembler: in an a.out
     executable, external labels get _ prefixed to them; in an ELF
     executable, they don't.  This makes no difference until you start
     integrating hand-written assembler: all the labels of the form _foo
     must be translated to foo, or (if you want to be portable about it)
     to EXTERNAL(foo) where EXTERNAL is some macro which returns either
     its argument (if __ELF__ is defined) or _ concatenated with its
     argument if not.

  o  Differences in libc 5 from libc 4.  The interface to the locale
     support has changed, for one.

  o  The application or build process depending on knowledge of the
     binary format used --- emacs, for example, dumps its memory image
     to disk in executable format, so obviously needs to know what
     format your executables are in.

  o  The application consists of or includes shared libraries (X11 is
     the obvious example).  These will obviously need changes to
     accomodate the different method of shared library creation in ELF.

  Anyway, here are two lists: the first is of programs that needed
  changing for ELF where the changes have been made (ie that you will
  need new versions of to compile as ELF), and the second is of programs
  that still need third-party patches of some kind.


  4.1.  Upgrade:


  o  Dosemu.  Modulo the three or four cuurrent dosemu development trees
     (don't ask, just join the linux-msdos mailing list), dosemu runs
     with ELF.  You'll need to monkey with the Makefile.  Current
     versions of dosemu are available from
     <ftp://tsx-11.mit.edu/pub/linux/ALPHA/dosemu/>

  o  Emacs.  Emacs has a rather odd build procedure that involves
     running a minimal version of itself, loading in all the useful bits
     as lisp, then dumping its memory image back to disk as an
     executable file.  (FSF) Emacs 19.29 and XEmacs 19.12 (formerly
     Lucid Emacs) can both detect whether you are compiling as ELF and
     Do The Right Thing automatically.

  o  MAKEDEV.  In some incarnations, this utility removes existing
     entries for devices before recreating them.  This is Bad News if it
     happens to touch /dev/zero, as said device is necessary to the
     operation of all ELF programs.  See the util-linux package(q.v.)
     for a fixed version.

  o  perl 5.001.  Perl 5.001 plus the ``official unofficial'' patches a-
     e will compile unchanged on an ELF system, complete with dynamic
     loading.  The patches are available from ftp.metronet.com or
     ftp.wpi.edu

  o  The cal program in util-linux 2.2 doesn't work.  Upgrade to version
     2.4 <ftp://tsx-11.mit.edu/pub/linux/packages/utils> or later.

  o  XFree86.  XFree86 3.1.2 comes in both a.out and ELF formats.  ftp
     to ftp.xfree86.org, read the `too many users' message that you are
     almost guaranteed to get, and pick the closest mirror site network-
     wise to you.  Once you have the contents of the common and elf
     directories, you must edit /usr/X11R6/lib/X11/config/linux.cf to
     change the lines saying



  #define LinuxElfDefault         NO
  #define UseElfFormat            NO





  to say YES instead.  Otherwise an xpm build will attempt to do odd
  stuff with jumpas and its associated relics of the past.

  o  Mosaic.  I don't have the facilities to build this myself, but the
     Mosaic 2.7b1 binary available from NCSA comes in ELF.  It has been
     linked against an odd X setup though, with the result that on
     normal systems it will complain about not finding libXpm.so.4.5.
     The simple fix is to edit it carefully with emacs or another editor
     that copes with binary files.  Find the occurence of the string
     libXpm.so.4.5^@ (where ^@ is a NUL --- ASCII zero --- character),
     delete the .5 and add two more characters after the NUL to aviod
     changing the file length.


  4.2.  Patch


  o  e2fsutils.  The Utilities for the Second Extended File System need
     a patch from
     <ftp://ftp.ibp.fr/pub/linux/ELF/patches/e2fsprogs-0.5b.elf.diff.gz>
     to compile correctly as a shared library.  Remy Card says ``This is
     the ELF patch which will probably be included in the next release
     of e2fsck and co''

  o  file.  This works anyway, but can be improved:
     <http://sable.ox.ac.uk/~jo95004/patches/file.diff> adds support for
     identifying stripped and mixed-endian ELF binaries.

  o  The Kernel.  As from at least 1.3.8, the development 1.3 series
     have a make config option to build using ELF tools.  If you are
     using the 1.2 series, you have two options:


     1. Patch the Makefile slightly to use the a.out compiler.  Just
        change the CC and LD definitions to be



          ___________________________________________________________________
          LD      =ld -m i386linux
          CC      =gcc -b i486-linuxaout -D__KERNEL__ -I$(TOPDIR)/include
          ___________________________________________________________________





     Alternatively,

     2. Apply H J Lu's patch which allows compiling the kernel in ELF
        (and also adds the ability to do ELF core dumps).


     Let me reiterate that neither of these is necessary for the 1.3
     series.

  o  ps (procps-0.97) The psupdate program needs a patch to work if you
     have compiled the kernel as ELF.  It's available in
     <linux.nrao.edu:/pub/people/juphoff/procps>, both as a patch to
     vanilla 0.97 and as an entire tar-file.  A new version of procps is
     expected to be released soon with this patch in place, so if you
     can find procps 0.98 by the time you read this, this patch will
     probably be obsolete.


  5.  Further information



  o  The linux-gcc mailing list is really the best place to see what's
     happening, usually without even posting to it.  Remember, it's not
     Usenet, so keep the questions down unless you're actually
     developing.  For instructions on joining the mailing list, mail a
     message containing the word help to majo...@vger.rutgers.edu.
     Archives of the list are at  <http://homer.ncm.com/>.

  o  There's a certain amount of information about what the linux-gcc
     list is doing at my ELF web page
     <http://sable.ox.ac.uk/~jo95004/elf.html>, when I remember to
     update it.  This also has a link to the latest version of this
     HOWTO, and the patches it refers to.  For US people and others with
     poor links to UK academic sites (that's nearly everyone outside of
     UK academia), this is all mirrored at
     <http://www.blackdown.org/elf/elf.html>

  o  See also Bobby Shmit's ELF upgrade experience
     <http://www.intac.com/~cully/elf.html> web page.

  o  The GCC-FAQ <ftp://sunsite.unc.edu/pub/Linux/docs/faqs/GCC-
     FAQ.html> contains much general development information and some
     more technical ELF details.

  o  There's also documentation for the file format on tsx-11
     <ftp://tsx-11.mit.edu/pub/linux/packages/GCC/ELF.doc.tar.gz>.  This
     is probably of most use to people who want to understand, debug or
     rewrite programs that deal directly with binary objects.

  o  H J Lu's document ELF: From The Programmer's Perspective
     <ftp://tsx-11.mit.edu/pub/linux/packages/GCC/elf.latex.tar.gz>
     contains much useful and more detailed information on programming
     with ELF.  If you aren't LaTeX-capable, it is also available as
     PostScript.

  o  There is a manual page for dlopen(3) supplied with the ld.so
     package.


  6.  Legalese

  All trademarks used in this document are acknowledged as being owned
  by their respective owners.  (Spot the teeth-gritting irony there...)


  The right of Daniel Barlow to be identified as the author of this work
  has been asserted in accordance with sections 77 and 78 of the
  Copyright Designs and Patents Act 1988.  (Proof by assertion

  This document is copyright (C) 1995 Daniel Barlow
  <daniel...@sjc.ox.ac.uk> It may be reproduced and distributed in
  whole or in part, in any medium physical or electronic, as long as
  this copyright notice is retained on all copies. Commercial
  redistribution is allowed and encouraged; however, the author would
  like to be notified of any such distributions.


  All translations, derivative works, or aggregate works incorporating
  any Linux HOWTO documents must be covered under this copyright notice.
  That is, you may not produce a derivative work from a HOWTO and impose
  additional restrictions on its distribution. Exceptions to these rules
  may be granted under certain conditions; please contact the Linux
  HOWTO coordinator at the address given below.

  In short, we wish to promote dissemination of this information through
  as many channels as possible. However, we do wish to retain copyright
  on the HOWTO documents, and would like to be notified of any plans to
  redistribute the HOWTOs.

  If you have questions, please contact Greg Hankins, the Linux HOWTO
  coordinator, at gr...@sunsite.unc.edu via email, or at +1 404 853
  9989.

- --- END Linux ELF HOWTO part 1/1 ---

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: finger gr...@cc.gatech.edu for public key

iQCVAwUBML4sgntNTo2suu5NAQG30QP/aV3s/P4XfqFoYuONGr8WFfscO+sR90eE
spqBwSblwK66SPumG1olbvCbsa9bwshtNb8kKhe+MIPAilU5KiM7WlrbaO8v9Dzc
vrsVrjJRBQQwlG34D1OonyZtlFA7LUE7WR3c1prXn3x/rPX9aeJ5VvaF0ZkosbAe
RckGo4qBa9I=
=SkVA
-----END PGP SIGNATURE-----

			        About USENET

USENET (Users’ Network) was a bulletin board shared among many computer
systems around the world. USENET was a logical network, sitting on top
of several physical networks, among them UUCP, BLICN, BERKNET, X.25, and
the ARPANET. Sites on USENET included many universities, private companies
and research organizations. See USENET Archives.

		       SCO Files Lawsuit Against IBM

March 7, 2003 - The SCO Group filed legal action against IBM in the State 
Court of Utah for trade secrets misappropriation, tortious interference, 
unfair competition and breach of contract. The complaint alleges that IBM 
made concentrated efforts to improperly destroy the economic value of 
UNIX, particularly UNIX on Intel, to benefit IBM's Linux services 
business. See SCO vs IBM.

The materials and information included in this website may only be used
for purposes such as criticism, review, private study, scholarship, or
research.

Electronic mail:			       WorldWideWeb:
   tech-insider@outlook.com			  http://tech-insider.org/