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.
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.
