(You've already read the first two pages of this article, haven't you? ;-))

Missing Or Unusual Build Files

The source directory doesn't contain a 'configure' file, what now?

In this case you have to deal with the 'Makefile' on your own.
Only some of the first few lines starting with words in capitals are of interest and may have to be changed. Makefiles may not contain all of these lines.

• CC = compiler tells 'make' which compiler to use. GCC should work in most cases. C++ programs may require G++ instead.
• INCDIR = -I/path/dir1 -I/path/dir2 etc tells 'make' in which directories to look for header files. Check if these comply with your setup.
• LIBDIR = -L/path/dir1 -L/path/dir2 etc tells 'make' in which directories to look for library files. Check if correct.
• LIBS = -llib1 -llib2 -llib3 etc tells 'make' which libraries are needed. Remember: '-llib' is short for 'liblib.so'. Uselocate liblib.so to check if the needed libraries are installed. Sometimes this variable goes by the name LFLAGS.

Now just run make.

What if the source directory contains an 'Imakefile', 'GNUmakefile' or 'Makefile.cvs' instead of an ordinary Makefile?

'Imake' is a predecessor to 'configure'. Running the command

xmkmf -a

will produce a Makefile from the Imakefile. This command is part of the XFree86-devel package. Then proceed as above.

There's no difference between GNUmakefiles and Makefiles, 'make' will handle both.

If you've got a 'Makefile.cvs', run

make -f Makefile.cvs'

This will result in a 'configure' file.

What if the source directory contains no build files at all?

First have a look for them in the subdirectories of the source directory. Then check if there are any other executable files:

find . -type f -perm -700

will list all executable files in the current directory and its subdirectories.

If you can't find anything, it is likely that you are supposed to run the compiler 'bare' on the source files. This is all the more likely if there's just a single *.c file. To do this:

gcc -o new_name file.c

'-o new_name' defines the name of the resulting binary. Omit the '-o' option if the directory contains more than one *.c (*.C, *.cc, *.cxx) file. In this case, the resulting binary will get the standard name 'a.out', you then might want to rename it to something sensible.

If you need to define extra include or library directories, or libraries, you have to do so by providing them as command line options to 'gcc' directly, e.g.

gcc -o new_name file.c -L/path/dir -llib -I/path/dir

section index top

Build File Problems

How come 'configure' complains about a missing library / header file although this library / header file is installed?

There are at least three scenarios which might lead to this error:

1. 'configure' doesn't find the directory which contains the library.
   this case, you have to add the full path of the directory which contains the library using the '--with-extra-libs=[DIR]' option to 'configure'. The same goes for header files ('--with-extra-includes=[DIR]').

2. 'configure' finds the wrong version of a library.
   Currently, a prominent example of this behavior are applications to be compiled with Qt2. 'configure' might fail with a misleading error message, if the installed minor version of Qt2 is too old (e.g. 2.2.1 when 2.2.2 or better is needed). In this case, you have to upgrade to a later minor version.
   Another problem frequently occurs if Qt1 and Qt2 (and Qt3 ...) are installed. By default, 'configure' looks for Qt in '/usr/lib/qt', but on ML, that's the directory where Qt1 is installed. Qt2 is in '/usr/lib/qt2', Qt3 in '/usr/lib/qt3'. In this case, you'd have to run 'configure' like this:
   ./configure --with-qt-dir=/usr/lib/qt2.

3. Typo in 'configure' script.
   Have a close look at the error messages in 'config.log', especially for capitalization errors in the library or header file names. This is very rare (had that once or twice in some years), but it can really drive you nuts if you don't think of this possibility, believe me ... ;-).

Why does my self-compiled binary lacks some features it should have?

It is up to the programmer to decide upon which missing libraries 'configure' or 'make' should abort with an error message. Thus a successful compilation doesn't guarantee that the binary is feature complete. Study the 'config.log' file closely to find out which libraries weren't found, install these, and run the process again.

section index top

Building Problems

I've installed a missing library, but 'configure' or 'make' still won't find it. Why?

'configure' and 'make' results are cached. Do a

make distclean

to clean up the source directory. Only by this you will ensure that they check the system anew.
If the Makefile doesn't offer a 'distclean' target, do this

make clean && rm config.cache

Another source for this kind of problem might be if the library has been installed to a directory which isn't listed in '/etc/ld.so.conf'. This file lists all the directories where the Linux Loader/Linker 'ld' should look for libraries in addition to the standard locations, '/usr/lib' and '/lib'.
If for example the newly installed library is in '/usr/local/lib' and that directory isn't mentioned in '/etc/ld.so.conf', this library isn't available to the system.
To fix this, add this directory to '/etc/ld.so.conf' and run (as 'root')

ldconfig

Now clean up the source directory and try again.

How do I fix library versions conflicts when all the needed libraries are installed?

In most cases the build process doesn't look for a specific minor version of a library. It relies on properly set up symlinks in '/usr/lib'.
Take for example the library listing of 'libungif.so' in '/usr/lib' (abridged):

lrwxrwxrwx /usr/lib/libungif.so -> libungif.so.4.1.0*
lrwxrwxrwx /usr/lib/libungif.so.3 -> libungif.so.3.1.0*
-rwxr-xr-x /usr/lib/libungif.so.3.1.0*
lrwxrwxrwx /usr/lib/libungif.so.4 -> libungif.so.4.1.0*
-rwxr-xr-x /usr/lib/libungif.so.4.1.0*

There are two versions of this library installed: libungif.so.4.1.0 and libungif.so.3.1.0 (marked with *). Plus there are three 'symlinks' (entries starting with an 'l'): libungif.so, libungif.so.3 and libungif.so.4.

'Symlinks' aren't 'real' files, they are just pointers to other files.
The build process would look in '/usr/lib' for 'libungif.so.3' and be pointed by the symlink to the actually installed minor version of this library, here 3.1.0.

Now assume the programmer had been a bit unspecific (accidents happen) and the build process would only look for 'libungif.so'. In this case, it would be directed to libungif.so.4.1.0, a different major version of the same library. Major versions are often incompatible, so if the binary relies on major version 3, but the build process finds major version 4 instead, 'make' or 'configure' will terminate with an error, most likely complaining about a 'missing library' or an 'undefined reference'.
Likewise, if a symlink with the name of a major version pointing to the actually installed library is missing, the build process will fail, too.

For the first problem, a quick and dirty solution would be resetting the symlink for the build process

ln -sf /usr/lib/libungif.so.3.1.0 /usr/lib/libungif.so

If you encounter the second problem, create the needed symlink with the 'ln' command. The first file argument is the existing file, the second the name of symlink you wish to be created for this file.

You should be careful when doing this, since it might break other programs. If possible, check back with the programmer, they know best.

section index top