Compiling Made Easy

From LXF Wiki

Revision as of 00:21, 16 Oct 2008; view current revision
←Older revision | Newer revision→

There’s a new version of your favorite program available, but no packages for your distro. What do you do? Compile its source code, of course! Mike Saunders shows you all you need to know...

Wiki post by Mr. Ben Figueroa. Original article written by Mr. Mike Saunders and published in LXF 111 (November 2008). For the original document in PDF click here.

Building software from source – that’s a bit old-school, isn’t it? Who wants to wrestle with the command line, hunting down dependencies and coaxing the GCC compiler into running properly? Well, it does sound like a strange thing to do in this world of binary packages and online repositories. We have thousands of packages available via the internet, all neatly compiled for our distros, thereby nullifying the need to get down and dirty with a Makefile. Or so it seems. As great as they are, binary packages have a lot of limitations that can only be overcome by compiling a program from its source code. Here are some of the benefits of building by hand:

  • Timeliness Get software as soon as it’s available. When CoolApp 2.1 is released, your distro will probably have only version 2.0, and (unless it’s a rolling-upgrade distro like Gentoo) you’ll have to wait until the next major release of your distro to get the new app. But by building from source, we can get the newest version of anything when it’s released.
  • Features In the interests of stability, distro vendors often disable experimental features when making a package, leaving you with a rather plain (albeit reliable) piece of software. When we go down the source-code route, however, we can turn on extra goodies – it’s our choice!
  • Optimisations When you compile from source, you get the chance to boost the program for your machine. Binary packages are built for a wide range of x86 processor types. Using certain compilation options, you can build apps specifically for your exact model of CPU, helping to wring extra performance from your PC.

To prove that it’s not as difficult as it sounds, let’s see how this works. The skills you learn here will put you in good stead for your Linux (and Unix-using) career, as the vast majority of programs can be compiled in this manner. We’re going to take a stock, unmodified Ubuntu 8.04 installation and install the Audacity sound editor, enabling some extra features along the way. Audacity is a good choice because it can throw up some strange errors during the compilation process, so we’ll learn how to deal with every eventuality.


Get prepared

First off, we need to get hold of the Audacity source code. You can find this on the project’s website at http://audacity.sf.net, or on the LXFDVD in the Audio section. Save audacity-src-1.2.6.tar.gz on to your desktop, then open a command line window (Applications > Accessories > Terminal) and enter the following:

cd Desktop
tar xfvz audacity-src-1.2.6.tar.gz
cd audacity-src-1.2.6

The first command switches us into the Desktop folder, and the second command extracts the compressed .tar.gz archive. (Note that for archives with a .tar.bz2 suffix, you should use tar xfvj instead.) Finally, we switch into the newly created source code directory.

Enter ls to see the list of files in the expanded archive. Along with various scripts (highlighted in green) and sub-directories (blue), you’ll see a README.txt file. It’s always worth having a quick peek at any file called README.txt or INSTALL.txt, as it may have useful information on building the program. Enter less README.txt to view the file, and hit the Q key to quit. In this case, we don’t need to read through it all – we can get straight to work on the compilation process.

The configure script will prepare the Audacity source code for compilation. Enter this command:

./configure --help

This executes the configure script (the ./ is required, as we’re running it in the current directory), telling it to spew out all available compilation options. If you scroll up through the terminal, you can see that there’s a huge range of options available to us. But don’t fret – we can happily accept the defaults. We’re going to make a couple of small changes though: firstly we’re going to enable the SoundTouch library, which provides extra pitch and tempo manipulation tools that aren’t included in the default Ubuntu package.

Another tweak we can make is to set the location of the installed program when it has been built. To do this, we use the --prefix option with the configure script. For instance, to install Audacity in the /usr/local directory (away from other software and easier to maintain), we use --prefix=/usr/local.

As mentioned earlier, another great benefit of compiling software from source is the choice of optimisations. By setting the CFLAGS (for C code) and CXXFLAGS (for C++) environment variables before we run the configure script, we can select the exact GCC compiler optimisations we want to use. This is a complicated subject, but we can get an extra speed boost very easily. Consider these commands:

export CFLAGS=”-O3 -march=core2”
export CXXFLAGS=”-O3 -march=core2”

Here we’re setting up the aforementioned environment variables with optimisations suitable for the Intel Core 2 CPU architecture. The -O3 bit at the start has a letter O, not a zero, and requests the third level of optimisation. (Most distributions compile their packages with -O2 for slightly smaller executables and easier debugging.) If you have a machine with a AMD64 chip, use -march=athlon64, and if you’re not sure, just use -march=i686 for wide compatibility. You can consult the GCC manual page (man gcc) for a complete list of supported CPU architectures, but it’s heavy reading!