Hot Topic #4 , "Compiling programs - How to make it work"

Section Index:
Starting Out: Finding depenencies & Configuring
Environment Variables and Makefiles
Yet more problems?

        When I first started out using .tar.gz files I remember having great difficulties in making almost anything compile. It was a real pain to me, as some software that I wanted was not in .rpm format. I had to learn it the hard old way, so hopefully I can alleviate the pressures for you.


Almost every program you install depends upon another program or library. A library is a piece of software that enables a series of functions to happen within a program. For example, all of the software written for the KDE interface depends upon an interface library called QT, which is made by a company called TrollTech. A lot of software written for Gnome uses an interface library called TCL/TK.
These are known as dependencies, but QT and TCL/TK are very basic dependencies. For example, you may want to install something like PGP or SSH, which requires a library called
The same thing happens with Windows, although it's just a lot more transparent. Ever wonder why you get .DLL errors? .DLL files are what Microsoft term 'Dynamic Link Libraries', which is just a fancy name for a library. When you install a program in Windows, it installs the libraries required too, because most of the time, these libraries come packaged with the software.

Because of the open source nature of Linux, libraries (which are almost always not written by the author of the software you are trying to install) are not packaged with the software you are installing. You need to obtain the extra library before you can install the software that you want to use. This is called a dependency, because one piece of software depends upon another.

To find out what dependencies a particular piece of software has, here are some good places to check:

  • The official web page of the software you have
  • The file README that resides within the .tar.gz file
  • The file INSTALL that resides within the .tar.gz file
  • Any other documentation you can find on the package, from places like Google

Configuring the software

When you are sure that your system meets all the dependencies, and all the versions of the dependencies are up to date, then quickly read over (or optionally print out) the INSTALL file to check if there are any special requirements to install the software. If the INSTALL file reads something like 'These are generic installation instructions' then you can be pretty sure that that means the standard 3-step installation routine applies:

  • ./configure
  • make
  • make install (as root)

Of course, the author of the software may have chosen a different path, and indeed, sometimes only a 'make', 'make install' or simply a 'make' is all that's required. The 3-step routine as above is the most popular though, and it is usually regarded as 'Autoconf'. This is because the ./configure bit of it works out what sort of system you have, and searches for dependencies. If you don't have a piece of software that the package requires, or the version on your box is not new enough, the configure script should tell you about it. If the configure script completes it's evaluation successfully, then it creates a file in the current directory called 'Makefile'. This file is what is used when you type make. If configure dies for whatever reason, it is likely to give you a reasonably friendly answer to the reason that it failed. Something like 'Could not find GTK+ 1.2 in path' is typical of configure, which means this: 'configure looked in /etc/ and didn't find any suitable reference to'. Something new there: /etc/, which is a file that is generated by a program called ldconfig. This binary cache file quickly lets configure know if a required library exists. So, as you can imagine, if you install a library for something, it's a must that you run ldconfig before you start to compile anything that depends upon it. Also, you'll find that there is a file called /etc/ This file contains a list of directories, which root can add to. If you add a library to a directory that is not already in that list, you'd best add it there, and then run an ldconfig again. Knowing this will avoid the common question, "Hey! I've installed that library! Why's it still saying that it can't find it?, it's right THERE!"

If you get past the initial ./configure stage, and everything seems to be fine, but then it all dies when you get to the make stage, most of the time, it's best to go over your configure again, and look closely at what it spits out to see if there is anything that you think looks odd. If you are convinced, however, that there is something that you can only fix by editing the result of the ./configure -- the Makefile, then reading the following will help:
You'll find that a lot of tarballs contain extra requirements in their INSTALL files, such as modifying a Makefile when you create it with configure (or otherwise), or checking your system has certain environment variables are set.
Firstly, type set at your command prompt. You'll see a list of every single environment variable that's set. If the instruction in the INSTALL file tells you to define a variable, you can usually do this by typing the following:


However, most variables are defined within the Makefile, so open up the Makefile, and have a peek in there. There may even be some comments to the effect of 'If you use Linux, uncomment this line, or if you use BSD, use this one'. Comments are delimited by a hash '#' at the start of a line.
Using the GTK+ example again, say your make dies because it can't use, and you think it's going to the wrong path to find this library, search through the Makefile, and find all references to GTK. You'll soon find stuff like: GTK_LOCATION='/usr/lib/', that's just an environment variable, same as your exported value, if it looks wrong, change it, and go back to the prompt. Type make clean - to clean up the mess it made before on the failed compile, and then type make again. Did it work? Great!, you fixed it. Did it fail? Get to work again!

You've tried doing basic debugging with ./configure, you've edited the Makefile, and still no luck. At this point, I do one or all of the following five things:

  • Delete the entire directory where I uncompressed the tarball into and try again
  • Read the docs that little bit harder, to catch the odd one-liner, like ones starting WARNING! ;)
  • Try an earlier (or newer) version of the software, maybe it ironed out the problems
  • Contact the author of the software (usually from his/her website) and provide lots of debugging info to get some sort of answer
  • Do a ./configure --help and work on the resulting output

All of the above options are all pretty self explanatory, apart from the last one, so let me explain:

If you are continually getting a dependency based problem, and you reckon that you've sorted out the file and you've got no reason to believe there should be dependency probs, sometimes ./configure is just messing around. Firstly, try removing the file config.cache (which is created the first time you do a ./configure -- that might work. If not, do a ./configure --help and look for anything relating to the error that you get. Again, taking our example of GTK+, I have done this one myself once or twice, with some software that depended on GTK -- which I did indeed have installed:

./configure --help | grep "gtk"

S Which basically means, get the output of --help (usually quite long) and show all results with the letters 'gtk' in it. I found the following was handy:


So I did:

rm config.cache
./configure --disable-gtktest

Guess what? - My program configured, compiled and installed successfully!
Hopefully you're now pretty good at configuring, so if you get any more problems on a larger scale, it's probably time to start asking people in places like our Forum