MandrakeUser.Org - Your Mandrake-Linux Knowledge Base!


 
 

* DocIndex - Basics

Compiling Source Code II

* Running 'configure'
* What's Missing?
* Running make
* Uninstalling
* Applying Patches

Related Resources:

Software Building HOWTO

Revision / Modified: April 21, 2002
Author: Tom Berger

 

* Running 'configure'

Nowadays most source packages come with a 'configure' script, which checks if the program can be compiled on the current system.

./configure --help

executed in the source directory, gives you a summary of available options to the 'configure' command. Don't get confused, default values should be OK in most cases.
There is one option, though, you should have a closer look at and that's '--prefix=[DIR]', very close to the beginning of the options list. This is where the compiled programs and libraries will be installed. The value is often set to '[/usr]' or '[/usr/local]'. Both values are alright, though I prefer to install self-compiled programs in the '/usr/local/' hierarchy because that helps keeping track of things.
However some KDE programs assume you have a directory '/opt/kde' and have this as their default installation directory. Mandrake Linux might have such a directory, but since KDE files are installed in the '/usr' hierarchy, you have to change that value by running 'configure' like this:

./configure --prefix=/usr

You might have wondered already why I wrote './configure' instead of 'configure'. This is because the freshly created source directory usually is not part of your shell path. So if you typeconfigure, the shell will say:

bash: configure: command not found

You have to tell the shell that you want to execute a command that is in the current working directory. And this is done by adding the prefix './' to the command.
More about path settings in Linux.

Notice that it is neither necessary nor recommended to run 'configure' scripts as 'root'.

* section index * top

* What's Missing?

Now 'configure' runs and checks your system. The process puts its output on the console and sends it to a new file called 'config.log'. It automatically stops if it encounters an error that would prevent the program from being successfully compiled.
It displays an error message and writes it to 'config.log', e.g.:

/usr/bin/ld: cannot open -lXt: No such file or directory
collect2: ld returned 1 exit status

Looks like there is something missing, but what is '-lXt'? That's a convention in programming: 'l' stands for 'lib...so'. So what's needed is the file 'libXt.so'.
Chances are that it is in some -devel-.rpm you haven't installed. If you are running Mandrake Linux 7 or later, use the 'Software Manager' (aka 'RpmDrake') to search for a package containing this file ('Tree - See available packages' and then 'Search - File') or use urpmf file on the command line.
On older releases, go to the directory on the CD which contains the RPMs (/mnt/cdrom/Mandrake/RPMS) and run this command:

for i in *.rpm ; do rpm -qpli $i | grep file && echo $i ; done

(Replace file with the name of the file you are looking for).
You will see that it belongs to 'XFree86-devel'. Install this RPM using your preferred graphical RPM application, 'urpmi' or via

su -c 'rpm-i XFree86-devel*'

Now delete the file 'config.cache' in the source directory and run 'configure' again. Repeat until 'configure' exits without errors.

If you don't find an RPM which contains the file you need (very unlikely) and the included documentation doesn't help you either, try to contact the author of the software. He or she knows best. But make sure you've checked everything (at least) twice!

* section index * top

* Running 'make'

If 'configure' was successful, it's now time for actually compiling the source with

make

There shouldn't occur any errors unless the 'configure' script was faulty (well, accidents happen).
Though 'make's error messages can be somewhat more obscure than those of 'configure', the procedure in such cases is very much like the one outlined above.
If something goes wrong, it is usually something like

file:line: file: No such file or directory

or

file1: in file | function name:
file2:line: undefined reference to function

In the first case, install the RPM which contains the missing file. An error containing a function name usually means that the program needs a newer or older version of a library than the one you have installed. See if you can find an updated or older version of this library and install it.

Always run

make clean

before trying to compile again.

Let's assume everything has worked out fine. Installation time! You have to be root to do this:

su -c 'make install'

Ready. You might want to check now if the program runs at all ;-). Make sure you put the binary in a directory which is part of your path, otherwise create a 'symlink' withln -s source destinationto '/usr/bin' or add the directory to your path.

* section index * top

* Uninstalling

Many people do not know this, but often it is quite easy to uninstall files that have been installed via make install. You just need the Makefile and then - being in the same directory as the Makefile - type:

su -c 'make uninstall'

provided the author defined this target in his Makefile (many do).

If you regularly install programs from source, you might want to have a look at CheckInstall, which builds simple RPMs from compiled programs and then installs those RPMs. This makes removing those programs much easier (you can use rpm -ename and also prevents dependency problems when you later install RPMs which depend on those files.
(Note to Mandrake Linux 8.2 users: do not use the CheckInstall RPM from your CD, it won't work. Get the RPM from the website).

* section index * top

* Applying Patches

A patch or diff file is a specially formatted text file containing instructions for the 'patch' program what and where to change source files.

A 'patch' command looks like this:

patch -pnumber <patch_file

The tricky part is the number after the '-p' option. This defines to what extend the file path in the patch file should be applied to your system:
'-p0' tries to apply the full path given in the patch file, '-p1' removes the first slash etc
Not specifying '-p' at all strips the whole path, which is perfectly OK if the patch only applies to file(s) all residing in thesame directory.

What usually works is putting the patch file in the parent directory to the directory of the source files to be patched, and running

patch -p1 <patch_file

If it doesn't, try other numbers to the '-p' option.

* section index * top

* Compiling FAQ


 
Legal: All texts on this site are covered by the GNU Free Documentation License. Standard disclaimers of warranty apply. Copyright LSTB (Tom Berger) and Mandrakesoft 1999-2002.