Recently I've received some mail asking for a brief explanation on how to build Linux audio applications from source code packages. Ask and ye shall receive, hence the following simple guide for the perplexed, the puzzled, and the downright mystified. Compiling software is hardly rocket science, and if an old guitar-picker like myself can do it certainly you can too.

This tutorial is written for users and developers who already know about Linux and who know how to use a Linux system. I'll demonstrate how to turn source code into software, using freely available tools and utilities common to almost every version of Linux. We will focus on the development of audio processing software. Linux has a powerful infrastructure for audio applications developers, and I hope that the material presented here will help new and seasoned developers alike as they venture into the world of programming Linux for music and sound.

Mainstream Linux distributions tend to be somewhat conservative about program versions. The distribution maintainers want stable and proven versions for their products, understandably so. Curiously, for all the chatter about Linux being for programmers only, the mainstream distributions are aimed squarely at the desktop. As a result, many popular distributions do not include the most current version of program X or utility Z. In Linux, it often happens that the very new is also the very unsupported. Mainstream Linux distributions may not have the dependencies or the specific versions of the dependencies required by an application, which leaves the user to do one of three things: You can wait until the distribution acquires the desired program in its package repositories, you can look for something else to do the job, or you can try to build the software yourself.

That last option is the focus for this article. A professional developer is not likely to need the advice offered here, but many other users want to know how they can compile and install Linux sound and music software from source code packages. The process itself is not difficult, but setting up a Linux software development system is often confusing for newbies (and even for not-so-newbies, especially if they come from a more GUI-dominated environment). This tutorial will help you decide which tools you need, how to acquire them, and how to use them to build and install a Linux audio program. But first, let's review the reasons why you might want to build your own software at all.

Why Compile ?

In Ye Olden Days of Linux there were few pre-built packages, so you were expected to know how to compile software you wanted to use. Books and other documentation routinely led users through the process of writing a test program and compiling it at the command prompt. By the way, "compile", "build", and "make" all mean about the same thing, and the terms are used interchangeably throughout this tutorial. Older users like myself may occasionally wax nostalgic about those yonder days, but in fact I'm a whole-hearted supporter of modern Linux distributions and their package repositories. The process of building software hasn't changed much since the old days, but some aspects of the process have been made much easier to handle. For example, I no longer need to compile the GTK and Qt graphics toolkits, a distribution upgrade usually updates those components to acceptable versions.

The mainstream distributions are likely to keep up-to-date with versions of major software development tools such as the Gnu C compiler (GCC) and the graphics toolkits already mentioned. However, they are less diligent about certain components needed by certain cutting-edge Linux audio software. Due to their concerns for stability, the major distributions are also unlikely to offer packages for the very latest versions of some applications, nor will they typically offer packages of alpha or beta stage development versions. For instance, if you want to test Ardour3 you'll need current versions of the libraries and development packages for (at least) the GTK2 graphics toolkit, libsndfile, JACK, ALSA, and the Scons build manager.

And that brings us to the main reason for compiling at all, i.e. to access features and capabilities not yet found in a public release. Building software from source code also ensures a "best fit" for your system's hardware. You might want a leaner version of a program, or you may need a capability available to a release version but not normally compiled into it. You might also discover that the program is currently unavailable in a packaged version, so if you want it you'll have to build it yourself. Lastly, you may be one of those strange people who just want to learn about such things and you aren't afraid to do it yourself.

IDE ? What IDE ?

I have purposefully avoided any discussion of GUI-based tools. There are some very nice GUI-based development tools and utilities for Linux, but for present purposes I have chosen to target the lowest common denominator of programming environments, the Linux command line (a.k.a. the terminal prompt). Regardless of flavor, size, or shape, all Linux distributions include command-line access to the system. And if you've never worked at a Linux console command-line, have no fear: If you can enter your name in a login dialog you can enter and execute commands at the terminal prompt. The power is in your hands.

The One-minute Guide To Rolling Your Own

The entire process of building software can be summarized by these steps :

1. Download and unpack the source code.
2. Compile the source code to create the program.
3. Install the program.

The second step includes a few sub-stages :

• Configure the source code for the resulting program's optimal performance.
• Compile the source code files (*.c) into object files (*.so).
• Link the objects together into an executable binary, i.e. the usable program.

That's it, and it really is that easy. Of course, I've ignored the possibility of things going wrong, and some of the indicated stages may require a few additional steps before the process runs smoothly to its end. I'll address those concerns later in this tutorial, but now we'll move on into a description of the tools you'll need to make a working program from a source code package.

General Environment

In its original state software is a collection of files known as the program's source code. Typically, source code is made of one or more files in simple ASCII text format, written in a computer language such as C/C++, Python, Lisp, Java... the list goes on and on. Computer programming languages are all capable of doing the same things, but they are not all equally capable. Thus, some languages are better than others for certain purposes. The C language happens to be an excellent choice for system software and other performance-critical software, such as programs written to manage audio data in realtime. Most Linux audio software is written in C or C++, so the remainder of this article focuses primarily on compiling source code written in C.

The following example is a variation on an old standard chunk of source code written in the C programming language :

  #include <stdio.h>

  int main()
  {
    printf("Greetings, Earthlings !\n");
    exit(0);
  }

After this code has been transformed into a working program you can run it and watch it print the message "Greetings, Earthlings !" to the screen. However, to turn that source code into a program that actually does something we need to acquire some tools and utilities specially designed for applications development. These tools make up what is called a build environment.

Most mainstream distributions provide a package named build-essential (or similar) that will add the basic tools for compiling, including the GNU compiler suite, a collection of compilers and other utilities needed for building software written in C/C++ (software written in other languages will require their own compiler). You will also need a build management system such as Scons or the GNU autotools.

And in case you don't know: A compiler is a specialized program that makes a working program out of source code. How it does so is beyond the scope of this article, so I'll refer readers to the controversial Wikipedia page on compilers to begin their investigations.

Before we can build any source code we need to retrieve some. A package can be acquired from the Web or an ftp site through a normal download. However, software on the edge is often not packaged at all, though tarballs of the daily builds may be available. You're likely to need some tools such as cvs (the Control Version System), svn, (the SubVersion system), and the git and hg systems, all of which should be available from your distribution's software repositories. These retrieval utilities access special regulated source code repositories known as version control systems, and their use typically requires an arcane command syntax like the following request for the source code for the Ardour2 "on-going" source tree :

    svn co http://subversion.ardour.org/svn/ardour2/branches/2.0-ongoing

This command accesses the Subversion (svn) repository and checks out the source code from the Ardour development team's 2.0-ongoing directory. An identical directory will be created on the target machine, and the software will be delivered to it file by file, with a revision number displayed at the end of the transfer. Updates can be performed with another special command, or the normal checkout command can be re-used (only updated files will be transferred).

The command for retrieval from a CVS repository is similar to the SVN example above. The following example demonstrates the 2-step procedure required for access to Csound's CVS sources :

    cvs -d:pserver:anonymous@csound.cvs.sourceforge.net:/cvsroot/csound login (Press the Enter key to login anonymously.)

    cvs -z3 -d:pserver:anonymous@csound.cvs.sourceforge.net:/cvsroot/csound co -P csound5 

Again, a new csound directory will be created so be sure to put it where you want to find it. $HOME/src works well for me.

Different developers prefer different version control systems. You'll need to check your selected program's Web site for the correct URL to its chosen version-controlled repository.

So Many Packages

If you download a package in the normal manner you'll need to unpack and install its contents. A variety of package formats exists, so let's look at some of the commonly encountered formats used for source code packages.

In the beginning was the tarball, and it was good. The tar utility organizes a directory into a file that is then typically compressed with a file compression utility. The following examples demonstrate how to uncompress tarballs created with these tools :

    tar -xZvf foo.tar.Z

    tar -xzvf foo.tar.gz

    tar -xjvf foo.tar.bz2

where

• x sets up an extraction,
• v runs a verbose list of the extracted files,
• f indicates that the extraction will be from a file,
• Z, z, j determines which compression/decompression utility to deploy.

By the way, "tar" stands for "tape archive", a reference to the days when digital data was stored on magnetic tape. The final part of the filename extension identifies the utility used to compress the file. Z refers to the UNIX compress utility, gz indicates that the GNU gzip was used, and the bz2 extension refers to a more recent compression format.

The tarball is still a preferred distribution format for source code, but you also might encounter source packages in DEB (Debian), RPM (RedHat/Fedora and OpenSUSE), RAR, Windows ZIP, and other formats. Each of these formats perform the same basic package functions as the tarball, and their basic unpacking commands are as follows :

    dpkg -i foo.deb

    rpm -uVh foo.rpm

    unzip foo.zip

    rar e foo.rar

    7z l foo.7z

RAR and 7z have been included merely for completeness. Those formats are relatively uncommon on Linux and are typically associated with large collections of soundfonts and audio samples.

Source code is also available in special RPM and DEB packages. These packages can be unpacked and compiled by their package management tools in one easy procedure, but the process lacks a configuration stage for user input. As we shall see, this pre-build configuration is an important part of the build sequence, one that should not be skipped if you want full control of the process.

A word of warning: Occasionally you'll discover a badly-formed package such as one that dumps all its extracted files into the active directory, i.e. the package doesn't create its own top-level directory. It is always wise to check the package organization with a content view option (tar -t foo.package) before uncompressing the package. If no parent directory is indicated you'll need to make one to have a specified extraction target. Be sure to move the package into the new directory and then unpack it there.

The Build Manager

Okay, you've downloaded some source code and you're ready to compile it. Before you can do so you'll need a set of tools that assist you in the configuration process and manage the compiler's interaction with the sources. The traditional Linux toolchain includes the GNU autotools (automake, autoconf, and libtool), but other popular utilities include Scons, the cmake system, premake, and the recent waf tools. Software built with the Qt graphics libraries usually require a run of the qmake utility, followed by use of the GNU autotools' make tool.

About Dependencies

Dependencies are software packages that are absolutely required in order to compile the target package. System dependencies include items such as kernel headers, X11 libraries and headers, and graphics toolkits such as GTK and Qt. The libraries themselves are insufficient to build software, you will also need to install the development packages for all necessary libraries.

Linux audio applications have some specific dependencies that are common to a wide variety of programs. You can expect to see requirements for the ALSA and JACK libraries and headers, the libsndfile library for soundfile I/O, and the development packages for the LADSPA and LV2 plugin systems. Other less critical packages include librdf (plugins metadata), liblo (a library for OSC functions), libfftw3 (Fast Fourier Transforms library), the Ogg/Vorbis libs (for OGG file support), and liblame (MP3 support).

Outro, Part 1

In my next article we'll complete the build process. Check in again soon for the final episode.