Maintaining old software on new systems

This post relates to a project at a previous employer, the University of Manchester. It’s nine months since I left, but I still maintain contact with former colleagues and have been meaning to write up this draft for a while now.

At the University of Manchester there is a piece of software called Komodo, which is an essential part of several computer science modules. It was developed many years ago for a specific purpose, and as it is more or less feature complete there haven’t been any updates for a long time. Unfortunately, in the meantime Linux distributions have moved on, and support for two dependencies (Glib 1.2 and GTK 1.2) has been dropped, so they can’t be installed via packages. On top of this problem, Scientific Linux 7.1 (the distribution that was about to be rolled out when I left) is 64 bit by default, and whilst it is still possible to install and link against 32 bit libraries, it’s not as easy as it used to be.

We had three possible solutions to the problem:

1. Rewrite Komodo to use versions of Glib and GTK which are included the Scientific Linux repositories (requires a move from 1.2 to at least 2.x).
2. Build the dependencies from source instead of using repository packages.
3. Find a replacement for Komodo.

Rewriting Komodo would have been a huge task, and not something which could be achieved before the start of the next academic year (or perhaps more accurately, we couldn’t guarantee to meet a September deadline). Finding a replacement was difficult as Komodo integrates with existing lab boards. There is another piece of software called Perentie, but it doesn’t have all the features of Komodo, and switching to it would require rewriting and re-testing all the lab notes (though I believe that is the long-term plan).

The only viable option in a short time period is to build everything from source, so we can guarantee library compatibility. Fortunately the GNOME project keeps source archives for all its releases going back as far as we need, though it would probably be a good idea to grab a copy just in case these archives are pruned at some point in the future.

Some of the problems we encountered during the process included:

• The config.sub and config.guess files, which give hints as to the underlying architecture, were out of date and didn’t include any 64 bit systems.
• GNU Make expects gtk-config to be in the path.
• OS X defaults to Clang as its compiler, which doesn’t support the nested functions GCC extension that is used by the assembler.
• Only certain versions of GCC can compile Komodo and its dependencies. The 4.x series works fine, but 5.x fails.

The final result of this work was the komodo-build script, which automates the bulk of the process (it downloads and builds Komodo and its direct dependencies such as GTK). For bonus points it also throws in cross-platform compatibility — it should work on Linux, OS X and Windows (with Cygwin).