10. Compiling

Now, after introducing you in the required tools and the structure of a source package, how do you compile it ? Well, from what you have learned in Section 8> and Section 9>, this would be fairly straightforward.


If you are installing into a system directory, you likely will need to su root before.


After installing a library, you need to run (as root) the command ldconfig, otherwise the library cannot be used. If you have installed the library into a directory that is not listed in the file /etc/ld.so.conf, you need to edit /etc/ld.so.conf to include that directory, and then run ldconfig.

10.1. If there is a Makefile

    bash$ makebash$ su root 
    bash$ make install

10.2. If there is a configure script

    bash$ ./configure (optional arguments)bash$ makebash$ su root 
    bash$ make install

10.3. In case of problems

Theoretically, the configure script (if there is one) should take care of all your system-specific issues that might cause problems. However, first, not all source packages come with a configure script, and second, developers can't look into the future and foresee all potential problems that may arise.

Software authors / developers usually take pride in their work, and would like it to function properly. Usually, you can find the email address of the developer somewhere in the documentation (sometimes, there is also an AUTHORS file). If you can provide the author with a useful problem report, you probably will receive help. However, you should be aware that simply telling the author "it doesn't compile" will help none of you both.

A useful problem report should contain informations such as:

  • What system do you have ? Use the command uname -a and include the output in your report.

  • What did you do ? What arguments / options did you supply to configure ? Consider including the output from ./configure in your report.

  • What happened ? Don't just say "it doesn't compile" — both ./configure and make will generate error messages if anything goes wrong. Include the full output in your report, not just the error message — an error message is often quite useless without knowing the context (e.g. which command was executed when / before the error occured).