Please read the updated information below if you are using Red Hat Linux 6.0 or 6.1!
Thanks to Andi Thul, who points out that the ld.so-1.9.5-5 and libc-5.3.12-28 packages are no longer archived by Red Hat at the original locations. Copies of these packages can now be downloaded from this site by following the links below.
Sorry, I am no longer maintaining this package, and I have no information on using it with later versions of Red Hat Linux, but I will update this document based on reports from users as long as there is any interest.
Adrian Bunk (Debian maintainer of libc5) writes:
In Debian on the i386 architecture a user simply has to install the packages altgcc and libc5-altdev (that are in the distribution) to find a fully working gcc for libc5 in /usr/i486-linuxlibc1/bin/ . This works in all stable releases including Debian 2.2 (potato) and will still work in the next release of Debian.
A frequent question on Red Hat's hurricane-list and other RH mailing lists asks how to compile and link to libc5 under RHL 5.0, but I have seen no clear answers. Responses are often variations on the theme of ``well-written software should compile properly with glibc.'' Of course, your programs and mine are invariably well-written, but (in moments of weakness) many of us have succumbed to the temptation to use large libraries, such as Motif or XView, that ... how to say this ... are just not quite up to this standard. (OK, the sources look like line noise phonetically transcribed into pig Latin, and I stopped reading after the first 10 megabytes, so perhaps I missed something.) Those of us who have other things to do in the next month or two may consider the task of converting these libraries into well-written software to be a bit off-track, and a pragmatic solution would be helpful. The Glibc2-HOWTO gives a few clues but is missing crucial details.
To remedy this limitation on RHL 5.0/Intel systems, download and install gcc5-1.0-1.i386.rpm (about 2.5 Mb), which includes:
a script that invokes the gcc version 184.108.40.206 compiler that was included with RHL 4.2
a replacement for the GNU
ldd 2.0.7 supplied with RHL 5.0; this
version correctly resolves links for binaries linked with either glibc or
libc5 (the standard version gives incomplete and often bogus information for
a copy of the RHL 4.2
/usr/include tree, needed by
run-time start-up files linked with all executables (from
symbolic links to
etc. The targets of these links are included in RHL 5.0, but the links
themselves are missing. These links are needed only at compilation time, not
at execution time. Thus their omission from RHL 5.0 does not affect the use of
existing libc5-based binaries, but makes it impossible to create new binaries
linked to libc5, libm5, etc.
a copy of the RHL 4.2
/usr/lib/gcc-lib/i386-linux/220.127.116.11 tree, needed
gcc5 (note the name change)
You will also need to have
ld.so-1.9.5-5, and it's a good idea to
libc-5.3.12-28 as well (presumably later versions would also
work, but these versions are known to work). Recent copies of the RHL 5.0
CD-ROMs may include these packages. If yours is an early copy, you can obtain
these packages from this site (download and install
The md5sums of these packages are:
(Newer versions of the last two of these packages are available here:
To compile and link a program to libc5, simply use
gcc5 instead of
gcc. In most cases, if you are using
make to manage
compilation, you can either:
CC=gcc5'' as an argument to the
CC=gcc5'' at the top of your
Warning: don't try to install
won't work, since
gcc5 itself is a script that invokes the real
You can verify that everything is working properly by compiling a program
gcc5 to generate an executable, and then using a command of the
foo by the name of the executable) to check its
ldd 2.0.7, supplied with RHL 5.0, attempts to do
this, but it doesn't know where to find libc5, or any other libc5-compatible
libraries; if you use that version of
ldd on an executable linked to
ldd reports ``
libc.so.5 => not found'', and other
libraries will be not found (or else they will be misreported if their sonames
match those of glibc libraries).
ldd5 is a replacement for GNU
ldd 2.0.7 that I've modified so that it can handle both libc5- and
glibc-based binaries; this is installed as
/usr/bin/ldd5 when you
If your program needs a libc5-compatible library other than those provided
with RHL 5.0 in
/usr/i486-linux-libc5/lib, the solution is to get this
library (from RHL 4.2 or another source) and install it in
/usr/i486-linux-libc5/lib, together with a
link pointing to it. The
gcc5 package already includes such a link
libXm.so.2, the Motif library; if you need a libc5-compatible
libXm.so.2, however, you will need to get it and install it in
/usr/i486-linux-libc5/lib yourself, since it is not included with RHL
5.0 or in the
gcc5 package. RHL 5.0 provides two versions of several
other libraries in
/usr/i486-linux-libc5/lib; in such cases, you
should choose which versions you wish to use when compiling with gcc5, and make
lib*.so links for those versions as required.
If you have all of the necessary RHL 4.2 files and just need the
gcc5 script, here it is:
#!/bin/bash export GCC_EXEC_PREFIX=/usr/i486-linux-libc5/lib/ gcc -b i486-linux-libc5/18.104.22.168 \ -I/usr/i486-linux-libc5/include \ -I/usr/lib/gcc-lib/i486-linux-libc5/22.214.171.124/include \ -L /usr/lib/gcc-lib/i486-linux-libc5/126.96.36.199 "$@"
A group of users of this package at INRIA Rhône-Alpes has kindly provided the information contained in this section (and much of the following section for RHL 6.0).
Two problems occur when using this package under RHL 6.1:
warning: libdl.so.1, needed by ..., may conflict with libdl.so.2 warning: libc.so.6, needed by /usr/lib/libdl.so, may conflict with libc.so.5This happens because the linker 'ld' uses libdl.so.2 instead of libdl.so.1.
gcc: file path prefix /usr/lib/gcc-lib/i486-linux-libc5/188.8.131.52/egcs-2.91.66/' never usedThis occurs because gcc has been renamed egcs in RHL 6.1.
To avoid these problems, after installing gcc5 as above, type the following commands (as root):
# the following lines mirror libdl.so.1* in the LIBC5 package cd /usr/i486-linux-libc5/lib/ ln -s /lib/libdl.so.1.* . ln -s libdl.so.1.* libdl.so.1 ln -s libdl.so.1 libdl.so # the following lines hack the GCC5 package to make it EGCS-like cd /usr/lib/gcc-lib/i486-linux-libc5 ln -s 184.108.40.206 egcs-2.91.66 cd 220.127.116.11 ln -s /usr/i486-linux-libc5/lib/*.o .
Then edit or replace /usr/bin/gcc5 so that it contains only these lines:
#!/bin/bash gcc -b i486-linux-libc5 \ -I/usr/i486-linux-libc5/include \ -I/usr/lib/gcc-lib/i486-linux-libc5/18.104.22.168/include \ -L /usr/lib/gcc-lib/i486-linux-libc5/22.214.171.124 "$@"
Note that in the finished version of gcc5, there should not
be a definition of GCC_EXEC_PREFIX as in the original.
Note for RHL 6.0 users
gcc5 works for me under RHL 6.0, and I've received reports from
several others who had no problems, either. A few users of RHL 6.0
did experience difficulties, however, which are related to the GCC_EXEC_PREFIX
environment variable set at the beginning of the gcc5 script. One of
these users was able to make things work by replacing
(note the extra '/' at the end). If you have problems and find that this workaround doesn't fix them, please send me a note.
After I posted the paragraph above, I received the following explanation of why this workaround works.
If one uses the original gcc5, there is an error during link edit. Some ".o" files from libc5 (e.g., crtbegin.o) are not searched for in the right place. $ gcc5 -c essai.c $ gcc5 -v -o essai essai.o Using builtin specs. Reading specs from /usr/lib/gcc-lib/i486-linux-libc5/126.96.36.199/specs gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) ld -m elf_i386 -dynamic-linker /lib/ld-linux.so.1 -o essai /usr/lib/crt1.o /usr/lib/crti.o crtbegin.o -L /usr/lib/gcc-lib/i486-linux-libc5/188.8.131.52 -L/usr/i486-linux-libc5/lib essai.o -lgcc -lc -lgcc crtend.o /usr/lib/crtn.o ld: cannot open crtbegin.o: Aucun fichier ou ripertoire de ce type gcc: file path prefix If one analyzes the trace: 19820 access("/usr/i486-linux-libc5/libcrtbegin.o", R_OK) = -1 ENOENT (No such file or directory) one notices that a "/" is missing between "lib" and "crtbegin.o". The double "/" is a workaround to solve this problem.
Another user, Torbjörn Gard, wrote to say that this also works, although gcc prints an apparently harmless warning message:
Torbjörn also notes that ldd5 is not needed with RHL 6.x since the version of ldd supplied with these releases works properly.
Finally, Tom Oehser wrote to mention his libc5 kit, which he says "has a script that takes an existing gcc/binutils and makes a libc5 compile setup without any rebuilding, and with only the headers and .so files in the kit." For the record, gcc5 doesn't require any rebuilding either, and does not require any headers other than those contained in gcc5. As noted above, gcc5 does not include any .so libraries, since mutually compatible and reasonably up-to-date versions of the libc5-compatible .so libraries are still included in current RHL distributions. Tom's kit includes libc.5.4.13.so, but he recommends against using any other shared libraries with his kit; as he points out, "It is never safe to mix libc5 shared libraries with other shared libraries unless they were also linked against [the same version of] libc5. This will most often be a problem with things like libcurses or libncurses, you really need to have 2 sets of everything, one for libc5 and one for glibc6." (RHL 5.x and 6.x provide "2 sets of everything" -- this is why it is possible to use these other libc5-compatible shared libraries with gcc5.)
Tom's kit is a bzip2-compressed tar archive, which unpacks to a README, an installation script, and another tar archive. It does not include a script similar to gcc5 (Tom recommends writing your own or just using the gcc command-line options), an ldd replacement (though, as noted above, you may not need one under RHL 6.x), or an uninstall script. Tom's kit is almost as easy to install as gcc5. The difference in size is mostly because gcc5 includes the gcc-184.108.40.206 compiler binaries. Unlike Tom's kit, gcc5 doesn't rely on compatibility between your existing gcc/binutils and libc5. If you have a slow link or severely limited disk space, and don't need to use shared libraries other than libc5 itself, you may want to try Tom's kit first, and gcc5 only if Tom's kit doesn't work for you.
Note that installation of
gcc5 does not affect the operation of
gcc itself in any way; specifically, you can continue to use
gcc to compile and link programs with glibc as before, with no
changes to your makefiles or anything else. If you figure out an easier way
to link with libc5 under RHL 5.0/Intel (or later), please
let me know!