2 Installation

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.

• 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).
• 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.
• 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.
• 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?
• 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.
• 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/.

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
   • using zsh as a shell (some versions of zsh define $VERSION, which seems to confuse instldso.sh)
   • 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.

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

... when you know there is such a file. This usually means 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.