Avoiding parallel installations

When you attempt to build a piece of software yourself, you need to watch out for older installations of that software already present on your system (either from a distro package or an earlier Do-It-Yourself build). It is important to avoid two (or more) parallel installations of the same software, as this tends to break things in subtle and mysterious ways.

With FFADO, the most likely candidates for headaches from accidental parallel installs are the JACK Audio Connection Kit, libraw1394, and FFADO itself (including its libraries and tools).

The problem

On most UNIX-like operating systems, there are two places to install software: /usr and /usr/local. Normally, all packages that are provided by your distribution and controlled by its package management system are put into /usr, and all stuff you build yourself is to go into /usr/local, to keep everything nicely separated. Some systems additionally use /opt to complicate matters.

To save memory, most programs are linked with their helper libraries dynamically, that is: at run-time. That means when you start a program, the dynamic linker looks into it and tries to find all required libraries. When you have two versions of the same program (and its required set of libraries) in different places, things can get mixed up, because the linker may have a different search order than your shell. You end up with an old version being linked to a new library, or vice versa, which will break things. Or maybe everything works, but you always get the old program version, not the one you just built.

The linker's search order is defined in /etc/ld.so.conf, and your shell's search path determines where binary programs are being looked for. If you have two programs called FOO, one in /usr/bin and one in /usr/local/bin, the search path determines which will be run.

Useful tools to poke around

You can use the command

$ which FOO

to find out where the FOO binary that would be run is located in your file system.

Your search path can be displayed by issuing

$ echo $PATH

Power users who want to learn more about which libraries are being used by a program can use the command

$ ldd /usr/bin/FOO

to get a list of libaries and their locations in the file system. Try those commands with "jackd" or "ffadomixer" to see what they do.

Another useful command when linker-related stuff goes wrong is

$ ldconfig

It will update your library search database if you have just installed new software that doesn't properly find its libraries. It has to be run with root permissions.

The solution

The obvious solution when you have a parallel install is to uninstall the distribution package. But there is a problem: the package manager knows that other programs may depend on the package you are about to uninstall, and will tell you you'll have to remove those as well. (The package manager cannot know that you are about to install a self-compiled program that will solve those dependencies.)

The easiest (if slightly nasty) approach is to keep the package so that the package manager is at peace, but to actually overwrite the old files with your new self-compiled version. This works most of the time. The only thing you need to do is tell your source to install itself in /usr instead of /usr/local (which is the default setting of most build systems).

With autotools-based build systems (they have an autogen.sh or a configure script), you can do

$ ./autogen.sh --prefix=/usr   or
$ ./configure --prefix=/usr

This is what JACK uses.

With scons-based build systems such as FFADO, you simply say

$ scons PREFIX=/usr

Those commands will make sure the software overwrites the distro package when you do make install or scons install.

Warning

If you already have an installation in /usr/local, be sure to remove it. Most well-behaved sources include an uninstall target to remove themselves from your system. Depending on the build system used, it is commonly invoked with

$ make uninstall    or
$ scons -c install

(You first have to cd into your source directory, of course.) Obviously, you need to invoke this command before you reconfigure your sources to the new installation path /usr!

If no uninstall target exists, you need to clean up manually by deleting all files related to the problem package in /usr/local/bin, /usr/local/lib or /usr/local/lib64, /usr/local/share and /usr/local/include.