Software Installation – How to Resolve Dependencies Without Destroying the Package Manager

makesoftware installation

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.

Best Answer

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

Related Solutions

Why do some packages use ‘make install’ while other use ‘sudo make install’

Usually I try to run it without sudo anyway - sometimes it works. Sometimes package creators think sudo is required, they use it due to their preference, or otherwise choose to install things in non-user areas of the system. Sometimes this is necessary, but many times it isn't.

The other common reason I see for the use of sudo is in blog posts by 3rd parties that explain how to install software, and rather than go the extra mile and explain to you how to install it without sudo privileges, they tell you to use sudo because the person writing the post simply uses sudo for everything, which isn't really a good idea.

Theoretically, the only reason a package should require sudo is if it needs (or decides) to install itself into/otherwise modify areas of the system that can only be modified via administrator access.

Generally speaking, fewer and fewer packages are still doing this, as the need for users to install some software without sudo access is growing.

Why can’t ld find this library

I was able to solve this with the help of the comments, particular credit to @Mat.

Since I wanted to compile the openmpi version, it helped to use mpif90 instead of gfortran, which, on my system, is

 $ mpif90 --showme
 /usr/bin/gfortran -I/usr/include -pthread -I/usr/lib/openmpi -L/usr/lib/openmpi -lmpi_f90 -lmpi_f77 -lmpi -ldl -lhwloc

Best Answer

Related Solutions

Why do some packages use ‘make install’ while other use ‘sudo make install’

Why can’t ld find this library

Related Question