Building the Application

Now we have the source code. We have to compile it to produce an executable program. To do this, we utilize some standard development tools to automate the process.

With the basic development tools in place, we are ready to configure and build the executable. The following is a generic synopsis of this process:

We have to configure the package in preparation for the build. There are two scripts that can be run to configure the source files. The first is called configure. Configure is the child of the other script that can be used. That script is called autogen.sh. Depending on how the source code was obtained and the packaging of the source, we will use either configure or autogen.sh.

Using autogen.sh

The only time you are required to use this script is if there is no configure script contained in the sources. This script will create the configure script from it's template file, configure.in.

This script will take any arguments it is given and pass them on to the configure script and run it. Most times you must run this script is when obtaining sources via CVS.

Using configure

This is the most commonly used script for configuring the source code for a particular architecture. To find all options that the configure script will take, you can use the --help option:

./configure --help

So, what is the ./ for? Well, in most cases, the path of a user does not include the current directory. This command is run from the directory in which it resides, so you must place a ./ before it or an error will be returned stating command not found.

There are a number of standard options to the configure script. The two most important ones are --prefix and --exec-prefix. These two options describe where you want to install the resulting executables. If you do not include these options, the default value is usually /usr/local. These options describe the top-level of the installation location. What this means is that all the various files will be installed under that directory or in a sub-directory of that directory. For example, most applications install into a bin directory. If you use /opt/mypackage as the argument to the --prefix and/or --exec-prefix, then files will be installed in /opt/mypackage/bin, /opt/mypackage/sbin (if there are system binaries installed), /opt/mypackage/share, /opt/mypackage/etc, /opt/mypackage/lib, and /opt/mypackage/ include. Other subdirectories may be created on the install, but these are the most common.

During the run of either of these scripts, checks are made against the system to ensure that the appropriate libraries and header files are present for successful building. If something isn't present, the scripts will tell you what's missing. Remember, even if the application is installed, you may need to install the application's development files (SRPM - RedHat, src.deb - Debian) . These are what source code requires to know how to build on the system.

Making the executable

Now that things are configured, we are ready to move on with running the make utility. Make simply goes through and builds the executables according to rules and targets. A rule describes how to make a target. A target is an action. For example, if you use the target clean, by typing make clean, then make will look through the file, Makefile, and attempt to find a target called clean. If it finds it, then it will execute the instructions, while adhering to the rules of how to make the target. However, this information is superfluous to actually using the program.

The actual commands for building executables is quite simple. To make the package:

make

Now that the build is complete, many developers and package maintainers will include a check target. This will double-check the build to ensure that everything was successful and correct. To check the build type:

make check

Not all source packages will have the check target. If the make check doesn't work, most likely the developer hasn't made a check target. So, now we move on to the install target. This will install the executables and supporting files in the location specified by the --prefix and --exec-prefix options to the configure script. If these options were omitted, most likely installation will be made to /usr/local. To install the software with make, type:

make install

Now we have everything done, right? If the directory you installed the program to is in your path, then your fine. Otherwise, you'll have to add the path to the executable directory (usually bin) under the top-level install directory. If you omitted the --prefix and/or --exec-prefix options, then you shouldn't have to change your path. Same if you used the option --prefix=/usr and/or --exec-prefix=/usr. The /usr directory is usually in every user's path.

And that's it! Enjoy your new software! Don't forget to stay on top of the latest patches and security fixes though. Especially for packages like SSHD.

Happy Hacking!