Linux Binary Compatibility: An Experience Report
Update from 2009
This is on a Debian Lenny AMD64 (64-bit) distribution. The old
binaries I tried to run are all i386 (32-bit) binaries.
A Mosaic binary from 1994 just segfaults, as well as all the other
ZMAGIC binaries (1994-1995) I have lying around.
The QMAGIC binaries (1995-1997) all report "can't load dynamic
linker '/lib/ld.so nor /usr/i486-linux/lib/ld.so'" and could probably
be made to work by copying the appropriate file to the right place
(plus any libraries needed).
Then we get into the ELF era (since 1998), and the binaries (e.g.,
ssh 1.2.25) work if (compatible versions of) the libraries they use
are present; for that ssh binary the libraries are libnsl.so.1
libcrypt.so.1 libutil.so.1 libc.so.6 /lib/ld-linux.so.2, which came
with the libc6-i386 package on Lenny. Not bad.
I usually preserve old distributions I used to use, so I can easily
copy the old libraries to my new distribution if I need them (or maybe
just include the old library directories in ld.so.conf). I have not
needed to do that for quite some time, though.
Original report from 1998
Some people have claimed that Linux is not a viable platform for
commercial programs; the reason they give is that Linux is constantly
changing, with a new kernel every week, and that there is not a
standard distribution; they claim that these things are an obstacle for
binary compatibility, and thus for commercial programs.
Here I report my experience with binary compatibility of programs
from kernel 1.0 to 2.0.34 and between two different distributions that
are more than 3.5 years and two major libaray versions apart and that
use different binary formats.
For those who don't have the time to read the rest, the bottom line
is: Most programs I tested run on the spot in the new environment, and
most of the rest can be made to run with a few tweaks; every program I
tested ran to some degree, in the end, but a few did not produce
satisfactory results. The binary format and the libraries were no real
problem, because Linux still provides support for the old (a.out)
format and the Red Hat 5.1 distribution includes the old libraries.
In Autumn 1994 I installed Slackware 2.1. I first used it with the
1.0 kernel I had then, and later upgraded to 1.2.13 (with a few
intermediate steps). I also upgraded a few components (gcc once, the
X-server twice, when a new graphics card made it necessary). I had no
problems with binary compatibility during this time, with one
exception: upgrading to the 1.2 kernels also required an upgrade of
bootpd (boot protocol deamon, which I used for booting an X-Terminal).
A few days ago, in June 1998, I installed the Red Hat 5.1
distribution, and I currently run it with the 2.0.34 kernel.
The main changes (with respect to binary compatibility) in the
meantime have been the switch from the a.out binary format to the ELF
format, and changes in the library that resulted in two major version
number changes (indicating that the library is not binary backwards
compatible): the switch from a.out to ELF resulted in bumping the libc
major version from 4 to 5, the switch to glibc 2 caused another bump
of the major version number to 6.
I performed the test on all binaries I had in my /usr/local/bin
directory. I copied the whole /usr/local hierarchy from the slackware
to the Red Hat installation (yes, I should put /usr/local on a
separate partition). All of these binaries are in the a.out
format. These binaries belong to several packets:
- WWW browser NCSA Mosaic 2.4, statically linked (due to
- a drawing program.
- a graph visualization program.
- another graph visualization package.
- a linear programming problem solver.
- compiler generator (for attributed grammars).
- compiler (gcc-2.6.3 with some Intel enhancements).
- SGML parser.
- floppy control and formatting programs.
- CD player.
- set sound card's mixer
- Forth interpreter.
- game (Defender clone).
- programs dealing with the texinfo documentation format.
The status indicator below means:
- runs, tested on some real input.
- runs, but not tested on serious input (because it is quite a
bit of work, or because I am not interested in the program and don't
know any serious input).
- does not run satisfactory.
- needed tweaks; look for remarks below.
binary package result
Mosaic Mosaic y
dot graphviz r
dspserver ldefx y
fdrawcmd fdutils y
fixref sgmls r
floppycontrol fdutils y
gcc-i2.6.3 gcc y
getfdprm fdutils y
gforth-0.2.1 gforth y
gforth-0.3.0 gforth y
html2html sgmls r
info texinfo yt
install-info texinfo r
ldefx ldefx yt
lefty graphviz nt
lp_solve lp_solve y
makeinfo texinfo r
neato graphviz r
ox ox r
prtgif tgif y
rtf2rtf sgmls r
setfdprm fdutils r
setmix setmix y
sgmls sgmls r
sgmlsasp sgmls r
superformat fdutils r
tcldot graphviz n
texindex texinfo r
tgif-2.16pl12 tgif y
tgif-2.12 tgif yt
tkdot graphviz n
workman workman yt
xvcg xvcg yt
- The compiler runs and produces assembly or object
code. But when linking it misses a file crt0.o. Using that
file from the Slackware distribution does not help, because then we
get many unresolvbed symbols from this file. Apparently it is not so
easy to get a compiler configured for a.out binaries running in an ELF
- file path changed (/usr/lib/terminfo/x/xterm ->
/usr/share/terminfo/x/xterm). I added a link to make it run.
- at first I had no sound, because the appropriate file was
not installed in the /usr/local hierarchy (IMO this is a bug in the
installation script of the application). After fixing that, it did run
with some warning about the minor version of libXpm.so.4.
- runs, but does not display characters (only the
graphics); it complains "Warning: Unable to load any usable
fontset". This makes it unusable, so I classified it as n.
- tcldot, tkdot
- Even if I help by supplying the TCL_LIBRARY
environment variable, they do not run, complaining about the TCL
version. However, since I did not use these programs earlier, I do not know if they ran on Slackware.
- tgif-2.12, xvcg
- did not find it's library (does not use ld.so); adding a symbolic link in /lib helped.
- this program requires the OpenWindows/Open Look
libraries (a toolkit advocated by Sun once upon a time), which are not
included in Red Hat 5.1. I copied them from the Slackware
distribution to /usr/local/lib/openwin, added that directory to
/etc/ld.so.conf and ran ldconfig. Now workman works.
Most programs run smoothly because the kernel supports the a.out
format and because the distribution includes the old libraries (except
the OpenWindows libraries). Differences in library paths are taken
care of by ld.so (except for ancient binaries that do not use ld.so).
There were also few problems with file paths, although at the time
of Slackware 2.1 the File
Hierarchy Standard was not as refined as today (and I don't know
how well Slackware complied).
Note that some of the tweaking (e.g. info and ldefx) was necessary
due to my testing post-installation compatibility, and would not occur
if the program was installed on Red Hat 5.1 with its install
script. To improve post-installation compatibility (i.e.,
compatibility over system upgrades), I recommend shifting work like
file-finding from installation time to run time as much as
The failures were due to the interaction with other components: the
binutils and libraries for gcc-i2.6.3, Tcl/tk for tcldot and tkdot,
and probably some X issue for lefty.
This poses the question whether scripts are not just as much of a
problem as binary compatibility, but I will leave a thorough
investigation of this to someone else; in general, I believe that a
script that works between different Unices can be expected to work
betwenn different Linux versions.
I expect that the platform will be more stable in the future than
in the past (due to efforts such as the File Hierarchy Standard and
the Linux standards base,
so we can expect even better binary compatibility for packages built
Every program I tested ran to some degree even though there were major
upgrades of the kernel and the libraries; the reasons are that the
kernel is backwards compatible, and that the distributions include old
libraries in addition to the new ones. Some programs needed some
tweaking before they ran. File path problems proved less common than
A few programs ran, but did not work satisfactorily, due to various
interactions with other components.
I expect even better binary compatibility for packages built
nowadays, on a more stable platform.