# Installing from source. How to resolve dependencies without destroying the package manager

Compiling and installing software is a pain and problem I cannot overcome. I just want to run down through my understanding of this process with someone more knowledgeable to clear my mind to get to the next level.

Many scientific software I need are not distributed as packages. I understand "./configure" sets up the compilation variables and checking for dependencies "make" does the compilation "sudo make install" puts all the libraries and bins in their places. However it never works. I rarely get out of the a) "./configure" stage without entering dependency hell, and if I do, b) "sudo make install" will probably nuke my box.

a) The dependency hell is very frustrating. Sometimes I have the library, but it doesn't like it. Or the library doesn't want to install. Or "configure" can't find it. Or my distro placed it somewhere it shouldn't be. Or there are two versions in my system. Problem is, I can't understand how to diagnose and therefore fix these problems. What are some good references to learn for someone who doesn't need to become a programmer?

b) My understanding is "make install" will replace some libraries and change settings without my package manager being aware of this. Therefore, some programs won't run, others can't be updated. So, if I don't use "make install", and just keep the compiled binary in my user directory with a symbolic link added to the PATH, will I be in the clear?

My box is single user, has tons of free HD so I don't really care about having multiple (dozens) of copies of libraries if that will solve my problems. Space is cheap.

• You do not say which distribution you are using, that would be an interesting piece of information. If you run a Debian derivate you can use apt-get build-dep <package> to automatically install the necessary dependencies. – Marco Jul 25 '12 at 16:38
• I use CentOS 6 (to have what the super-guru in our lab uses), but I used to use Ubuntu. – Lenz Jul 25 '12 at 16:46
• Welcome to the life of a distribution packager. Doing all this dependency tracking is not particularly hard, but it's drudgery. – Gilles Jul 25 '12 at 23:12
• See Non-Root Package Managers and perhaps other questions tagged not-root-user that are about software installation and package management. – Gilles Jul 25 '12 at 23:13

Most packages will have a <package>-dev (for Debian based) or <package>-devel (for Red Hat based) that will be the libraries needed to link against for building.

So, for example if the source says it requires libxml, in Debian based systems you'll find libxml2 and libxml2-dev (use apt-cache search <dependancy> to find them).

You'll need the libxml2-dev to build it, and libxml2 to run it.

The ./configure step usually supports flags like --with-libxml=/usr/lib/ to point it at the correct libraries (./configure --help should list all of the options). It also usually supports changing the install location with --prefix=\$HOME/sw. Using a prefix outside of what your package manager controls is the best way to avoid conflicts with package manager installed software.

On Debian & derivatives using a --prefix of /usr/local/ or /opt/local/ should be safe.

If a library (or version) you need isn't available from the package manager just download the source and compile it using similar options. Most importantly use a --prefix outside of your package manager and when compiling the software you really want use --with-<library>=/<path/to/installed/library>.

There is the tool auto-apt which can be used for this.

From man auto-apt:

auto-apt is a program that checks file access of programs running within auto-apt environments. If a program will access a file of unin- stalled package, auto-apt will install the package containing the file, by using apt-get.

It is used as follows:

auto-apt run ./configure


Another way is to use apt-get build-dep <package> on Debian based distributions.

• apt-get build-dep <package> worked for me. It was frustrating running ./configure over and over again to learn one more required package! – HeatfanJohn Mar 11 '16 at 22:49

For RPM based distributions, you could try your hand at creating proper packages (it isn't that hard...).

Benefits of a proper package are that your package manager keeps track of the software, and you can easily replicate your setup elsewhere/on the next machine. With a proper source package porting forward (new upstream version, bugfix patch, underlying libraries get updated) is easier than having to figure it all out from scratch next time.