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