Compiling Software Packages

This article was originally posted on the Lanka Linux User Group site.

What is a Tarball?

Tar was originally developed as a backup software for unix (Tape Archiving program). It collects several files to a single file (or standard output). A problem with the original tar program was that it could not compress data by itself, so another program called gzip, had to be used. Gzip is slightly different from other compression programs such as PKZip, ARJ, LHA or RAR. It operates only on one file and it does not create a new zip file. Instead it converts the old file to a compressed file and adds the extention '.gz', so the original file is no longer there. When decompressing, it simply works the other way round, converting the compressed file to the original file and removing the extension.

When it comes to collect several files (including subdirectories) to one single file, tar and gzip is used in combination. The command

tar -cvf myfile.tar *

will create a tar archive called myfile.tar, collecting all the files in the current directory/subdirectories. The option 'c' is for create, 'v' is to be verbose, i.e., to list the files that is being compressed, and 'f' to tell tar to write its output to the file whose name follows ('myfile.tar' in this example). If you did not give a filename with an 'f' option, output will be written to the standard output, and the screen will be filled with garbage. Type 'reset' to get the console back to the normal condition if this happens. The above tar file is then gzipped.

gzip myfile.tar

and 'myfile.tar' will be converted to 'myfile.tar.gz'.

Modern tar programs can do compression too. Therefore it is not necessary to run tar and gzip seperately. Instead just passing an option 'z' to tar will do the compression. Hence the above two commands are equivalent to

tar -czvf myfile.tar.gz *

Usually a software package comes with a set of files in a tar.gz archive. If the package name is 'mypackage' and its version number is 'x.xx', the archive is usually named 'mypackage-x.xx.tar.gz. To check its contents, give the command

tar -tzvf mypackage-x.xx.tar.gz

and to untar it

tar -xzvf mypackage-x.xx.tar.gz

Usually this will create a directory 'mypackage-x.xx' in the current directory and place the rest of the files, usually known as the 'source tree', under it. However, there are some rare cases, where the files will be created in the current directory (e.g. xfractint). In this case, it is necessary to create a directory for the source tree and untar the package in it. It is always a good idea to test the contents with the option 't' beforehand.

Some packages may have the extention 'tgz' instead of 'tar.gz'. In early stages of development, some packages use the release date instead of version number (e.g. wine).

Where to Untar a Package?

First, let us have a brief look at the unix directory tree. The following list gives some directories and their contents.

These directories exist in various levels. For example consider the 'bin' directory. There are several places where you get 'bin' directories

The story is more or less the same for the other directories. The root directory has standard unix directories. '/usr' has files related to the original installation. '/usr/local' has things that were added in addition to the distribution and finally the home directories may contain user specific directories.

There are few deviations too. For example '/etc' is shared by both standard unix programs as well as the programs that comes with a distribution.

Since, we are interested in compiling packages in addition to the original distribution, we will have to use the '/usr/local' directory. It is usual to untar source trees under '/usr/local/src', and to keep the tarballs under '/usr/local/tar'. Therefore, the process of extracting the source tree will be

cd /usr/local/src
tar -tzvf ../tar/mypackage-xx.x.tar.gz
tar -xzvf ../tar/mypackage-xx.x.tar.gz


Several software packages are built upon libraries. It is a good idea to have often needed libraries installed. Here is a brief list of them. Most of them are for the GUI.

To compile you need both the library and its header files. RPMs are usually available in pairs. For example, Mesa library has Mesa-xxxx.i386.rpm and Mesa-devel-xxxx.i386.rpm. The later contains the header files necessary to complile.

Several of the above libraries are available as binaries and it is easy for new users to install them that way instead of compiling them. RedHat users can get most of the libraries in RPM format from redhat powertools (see redhat mirrors - some of them don't mirror powertools bundle).

Configuring the Source Tree

Most packages come with a 'configure' script which is at the root of source tree. Just running './configure' is fine, but the following changes may be useful.

Static vs. Dynamic Libraries

Static libraries are the ones that are linked to the programs at the compile time. For example /usr/lib/libm.a is the math library and is linked to a program by giving the option -lm. A static library xyz has the filename libxyz.a and can be linked to a program by giving the option -lxyz. If the library is not in the default library path, you have to give the option 'L/foo/bar' to specify the path to the libraries. If a compilation stops with the error which indicates the absence of a library and if you know that the library is somewhere (find it by 'find / -name "libxyz.a"'), specify its location by the -L option or edit the corresponding Makefile.

Dynamically linkded libraries have the extension 'so'. The file /etc/ld.so.conf contains the directories where these libraries are found. If you add a new library to a directory which is not listed there, edit that file and run ldconfig.

Include Files

Usually the default include directories are '/usr/include' and '/usr/local/include'. Some programs expect include files to be in a subdirectory. For example Xlib include files are in a X11 subdirectory and C programs will have the line

#include <X11/Xlib.h>

There are rare cases the program conflicts with the include file locations. Here is an example. The Flight Gear flight simulator needs the header files from plib library to be in a plib directory (/usr/include/plib or /usr/local/include/plib). However, the default installation of plib copies the include files to /usr/local/plib/include. To overcome the problem you can add a link from /usr/local/include to /usr/local/plib/include with the name plib (ln -s /usr/local/plib/include plib). Now there is a /usr/local/include/plib (actually /usr/local/plib/include) and it will contain plib include files.

Compiling and Installing

Usually compiling and installing are done by giving the commands 'make' and 'make install'. It is safe to do a 'make check' before 'make install' to make sure things are well.

Some system administrators like to compile software as a user rather than root and login as the root only to do the installation (make install). This is good if make takes a long time and leaving the computer with a root shell is unsecure.


Usually the source tree contains a README file (may be more than one) and an INSTALL file. Read them FIRST!. They contain valuble information that will save time. Remember that some packages have unconventional installation procedures.