Menu

Compiling software under linux

Introduction

As a linux user, you might have to compile your applications sometimes. Usually because

• the software you want to use is not available for your distribution
• because you want an up to date, eventually experimental version
• because you want to patch the sources or hack them quickly

You will be guided step by step on the procedure. This is intended to be a short guide on how to compile your software on your linux desktop.

The whole process is very fast, but I will cover it lenghthly so you understand what you're doing. Understanding will give a meaning to what you do, it is absolutely required for everything you do, computer related or not.

Requirement

There is almost no prerequesites except knowing how to handle the shell a little bit (Changing directory, listing content of a directory, etc). You will also need to install the build tools (gcc and dev libraries for the dependencies of the software you are building) for your distribution (if it is based on binaries).

Compiling from a tarball (.tar.gz / .tar.bz2)

Compiling your application is basically 4 short steps.

• unpack
• configure
• build/compile
• install

Unpacking

Most software sources releases you will find comes in the form of a tarball. But what's called a tarball? We call tarball those files with the .tar.gz and .tar.bz2 extentions. They are in fact compressed archives of the source. The first thing to do is to unpack the source. To do so, you will use the tar command (with the correct filename of course).

$ tar -xzf archive-XX.tar.gz

or

$ tar -xjf archive-XX.tar.bz2

depending on the file format. So, basically, for your information (note that you can get all information about the command by reading it's manpage $ man tar),

• -x means that we want to extract the archive
• -j means that the archive is in the .tar.bz2 format
• -z means that the archive is in the .tar.gz format
• -f means that what will follow is the filename

Configuring

Once the tarball has been extracted, go into the directory (with the cd command, use the ls command if you don't know the name of the directory). It's time to define how the software is going to be built. Indeed, most software support some options at build time. As an example, while building some image viewer application, you could define at build time what formats it could support. If we did want to use the default settings, we would simply type (as most software autodetect most of the features)

$ ./configure

Configuring software:

• Allows the software to discover what computer will be running on, adapting to your versions of the libraries and on which are or not present
• Allows the user to choose what he wants to be built in the software and what he wants not to be built.
• Allows the user to choose where the software is supposed to be installed

Now, you are going to ask why not enable everything? Well, simply enough because of dependencies. Most software relies on other software to run (for an image viewer as instance, it will rely on a display API to display it's window, but also on different libraries which will handle the different file formats). Also note than more you add, slower and bigger the software will be. You may usually get a list of compile flags by typing

$ ./configure --help

Once known, your final command line will look like

$ ./configure --enable-featureXX --enable-featureYY --disable-sound

The last thing you can specify with configure is where and how is application will be installed. It's usually by default in /usr/local/, which is quite a good place as most linux distribution install software in /usr/ allowing the software you install to remain separated from the rest. Note that if you want to install some software without any root privileges, you may choose to install it in your /home/username. You may also alter the name of the software you are installing. This is very useful if you want twice the same software in a different version (like, one stable and the other devloppment version, like, named gaim and gaim6.5beta3). Like that, they won't interfere. It all can be resumed to the pseudo command

$ ./configure --prefix=installationpath --program-suffix=suffix --program-prefix=prefix

like, in this example :

$ ./configure --prefix=/usr/local --program-suffix=6.5beta3

Building

Alright, now we have to compile the software, just type

$ make

Installing

Alright, now we have to install the software, become root then type (in ubuntu, becoming root is sudo su rather than su

$ su
# make install

Special Note : Debian/Ubuntu/Red Hat/Fedora/Slackware

Though using the make install thing will work, the freshly installed application will not fit into your package manager. There is a simple application that will create a package for your distribution and install it, it's called checkinstall. Install checkinstall for your distribution then, rather than typing make install, type

# checkinstall

This is very interesting as it allows you to uninstall the software through the package manager.

Compiling from CVS

Sometimes, there is no tarball and you are being told to get the sources from CVS. This replaces the extract tarball part from the previous section. The rest is usually very much the same. Note that understanding how to use CVS is a bit beyond the scope of this guide. You should read the manpage and refer to the official documentation.

$ cvs -d ':pserver:anonymous@cvs.server.com:/cvsroot/my_app' login
(If it's a public repository, leave the password empty, or eventually try 'cvs')
$ cvs -z3 -d ':pserver:anonymous@cvs.server.com:/cvsroot/my_app' checkout my_app
$ cd my_app
$ sh autogen.sh
$ ./configure
(...) 

Note that the sh autogen.sh command is only required when the folder does not containt a configure script.