"Linux Gazette...making Linux just a little more fun!"

Sooner, or later, everyone will download a program in source code and try to compile it. Even if you are avid follower of Red Hat or Debian, you will eventually find a program that is either too old, or too new, to find a precompiled binary. The bad news is that the code will not always compile no matter what you do - remember, most linux programs are beta at best. The good news is that the percentage of programs that compile without problems has increased significantly over the past five years, and that there are things you can do to "fix" code that will not compile without being a programmer.

After you download: you now have some sort of tarball on your disk. First you must uncompress it and untar it to a directory. By convention, most people untar programs to the directory: /usr/src. This keeps everything in one place so you can clean it after time, as well as keep track of which version of the program you have compiled. You will need to be root to use this directory. The linux tar program can uncompress and untar a file at the same time if the file was compressed using gzip. If you have a file named: filename.tar.gz, you can cd to the /usr/src directory and type:

    tar -xzvf /{path to file}/{filename.tar.gz} [Enter]

and it will uncompress and untar. Here is a quick explanation of the flags:

    x - untar the file
    z - uncompress the file
    v - verbose - so you can see what is happening
    f - what follows is the file you want to untar

If you used Netscape to download the file, you might get an error. Sometimes Netscape will uncompress the file for you. So if you try to untar it as listed above you might see:

    gzip: stdin: not in gzip format

Try the same command, but leave out the z. So it looks like this:

    tar -xvf /{path to file}/{filename.tar.gz} [Enter]

Instead of gzip, many files are using bzip2 for the compression, so your file will look like: the-program.tar.bz2. The z flag for tar will not work. The easiest way to untar the file is to type: bunzip2 the-program.tar.bz2. This will give you the file: the-program.tar, which you can untar using:

    tar -xvf /{path to file}/{filename.tar.gz} [Enter]

After untaring: cd to the directory that was created when you untared the program. Look at the files in the directory: ls. You have to read the README and INSTALL files. Do not think you will get the slightest bit of help from anyone if you do not read these files. There is a reason why RTFM is one of the most common expressions on the net. The README and INSTALL files should tell you how to compile and install the program.

To compile, you issue the "make" command. In order for "make" to start compiling, it must have a file named: Makefile (you could issue "make" options on the command line, but that is beyond the scope of this article.) There are three common ways to start the compile: simple, Imake, and configure.

Simple compile: If you see is a file called Makefile - no Imake or configure files, you are going to use this method to compile. This method of compiling has the most problems because nothing is configured to your computer. Often times the README and INSTALL files will tell you to edit some files so it will compile. Usually you can then type:

    make [Enter]

and if all goes well, you can now run the program.

Imake: If you ls the directory and there is an Imake file and no Makefile, you use this method. This is an older way to setup the compiling. Basically, you type:

    xmkmf [Enter]

Configure: Use this method of compiling if there is a file named configure in the directory. This is the easiest way to compile and probably has the highest chance of compiling correctly. Essentially it checks your entire system for every possible library and support file to ensure you can compile the program, and then creates the Makefiles with the correct information. To compile, type:

    ./configure [Enter]

Notice the ./ in front of the first command. When you type a command, you shell looks for the files in your path. It does not start looking in your current directory, so if ./ (which means: current directory) is not in your path, even though ls can see the file, your shell can not it. The shell can execute make because it is usually in /usr/bin which is in your path. To see your path, type:

    echo $PATH [Enter]

If things go wrong:

The most common cause of not compiling is missing files. Almost all programs rely on support programs/files/libraries. If they are missing, the program can not compile. The README/INSTALL files should have told you which files, and which version of the files, you need to compile the program. Note: the wrong version will kill you just as much as not having it at all. Usually you will know if this is the problem because the error statement at the end of the compile will tell you it can not find a certain file. Note: sometimes you have the file, but it is not where the Makefile says it is. Use your linux distribution install program, e.g. rpm, and check to see if you have the missing file. If not, go get it. If you do have it, and it is the correct version, check the Makefile to see where it thinks the file is. Example: say the file moc is in /usr/local/bin, but the Makefile says: moc=/opt/bin/moc. Then just edit the Makefile (with vi or whatever you use for text editing) and change where moc is located.

The next most common problem is missing include files. Most of the files in the program source directory have lines near the top that look something like this:

    #include <gtk/gtk.h>

These "h" files (or headder files) must exist on your computer. As a minimum, check that you have the kernel headder files by: ls /usr/include/linux. If you have installed libraries, like gtk, make sure you have also installed the devel files for them as well. Sometimes having multiple versions of the same library can cause problems as each version could put its header files in different places and you will not know which files the compile will use.

If you have made all the necessary changes to the Makefiles and have all the libraries and include files and it still will not compile do the following IN ORDER:

1. If you downloaded the program from a site other than the home site for this program, go to the home site and see if there is a newer version available.

2. Go to www.dejanews.com and search for your program. It is very likely that others have had the same problem and posted solutions.

3. If all else fails, email the author. Most program authors are very interested in improving their program and bug reports/suggested improvements are usually well received (remember: this is linux, not commercial software.) Note: your bug report had better say something more than "it did not compile"! I usually email the last 10, or so, lines from the xterm compile window so the author can see exactly where it died. If I really like the program, I will email the author after every new version and give him/her as much useable feedback as I can. Please note: programmers are humans too - they go on two week vacations, change jobs and locations, and some even have to go to class once in a while, so do not expect an immediate reply.

Lastly, there are some programs that have unique compile setups: qt and the kernel come immediately to mind. To compile them, I will beat the horse one last time: read the README and INSTALL files!