It turns out that I routinely use some really old Linux binaries

February 21, 2015

With all of the changes that Linux has gone through over the past ten or fifteen years and with them all of the things that have stopped working, it's easy to wind up feeling that Linux doesn't have a really good story about backwards compatibility. Certainly this is true to some degree and I have various programs that have broken over this time, sometimes to my significant irritation. But at the same time it turns out that some parts of the Linux binary world have been remarkably stable.

How stable? Well, let me give you two stories.

The oldest Linux binary that I'm sure I use on a routine basis was compiled on January 29th 1998. This was almost certainly very shortly after I installed my very first Linux machine, as the source code itself is older than that (it's a standard helper for my dotfiles that dates back to at least 1995). I've faithfully carried my $HOME forward from then onwards and with it this program, which has just kept on working. It's a 32-bit program of course, dynamically linked against glibc, and strings suggests it was compiled with GCC 2.7.2.3.

(I know it was compiled on Red Hat Linux, and given the date it would have been Red Hat 5.0.)

The second impressively old binary that I still use regularly is an X-based program that was compiled on June 12th 2000. As an X program it's dynamically linked against not just glibc but a whole series of additional X libraries. All of them have kept ABI compatibility and have not changed their .so versions. In fact now that I look I see that I routinely use an even older X-based program, compiled May 5th 1999, which is actually a core part of my automation to do things with the current X selection.

(My personal binaries directory is overgrown and many of the contents are utility programs used by scripts, so I don't always remember off the top of my head which programs are still in use by scripts that I still use. I really should weed it out a lot, but that would take time and energy.)

There are plenty of Linux binaries that would and did not survive that long. Offhand, anything written in C++ (due to repeated C++ ABI shifts), anything using termcap and (n)curses (due to .so version changes), and anything using Berkeley DB (ditto) would have been lost at some point. And of course many high level GUI toolkits are hopeless; ABI compatibility is nil over time and distributions just don't carry old versions forward in compatibility packages. But apparently basic X is just low level enough that it hasn't been impacted.

(It turns out I have binaries from 2000 that use libXaw, the old Athena widget set. Once I actually fetched the 32-bit libXaw for Fedora 21, they still ran. I guess no one's been fiddling around with Athena widgets any more than they've been meddling with the core X libraries.)


Comments on this page:

By Chris N at 2015-02-21 10:24:44:

To be fair, the X binary isn't really about "Linux" compatibility per se. It's still impressive, but it's not really something that the "Linux" community can take credit for. X has always been about backwards compat, which is why things like xcb were developed.

By cks at 2015-02-21 19:57:21:

The core X libraries have always been pretty good at API compatibility and (as I mentioned) there's not much changing in them anyways; all of the action is with higher level toolkits. But a lot more than just API compatibility goes into this degree of ABI compatibility over time, since there's a lot of things that can perturb it. There are plenty of Unix systems that deliberately don't have this degree of ABI compatibility within the X libraries over anywhere near this span of time because, for instance, they've changed library .so versions for their own reasons.

Written on 21 February 2015.
« All of our Solaris 10 machines are now out of production
Unsurprisingly, random SMTP servers do get open relay probes »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sat Feb 21 01:17:58 2015
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.