Open Source

Use the source: Gain control over your applications by installing from source

Installing applications in Linux doesn't have to be a nightmare. Use the source and let your Linux Jedi powers prevail. Jack Wallen, Jr. guides you through the process.

“Use the source…” was a common phrase bandied about during the weaning period of Linux (I still have my T-shirt from my first Linux expo) that still holds true today. Although the rpm format has a great number of advantages (including ease of use and security), installing from source gives the installer more flexibility and results in a better optimization of the application for that system.

In this Daily Feature, I will introduce you to Linux application installation via source. I’ll cover what file types are used as well as how to use gunzip, bunzip, tar, configure, make, and make install to completely install a Linux application from source.

Use the source
Installing from source offers a few advantages (over installing from rpm) as well as a few disadvantages. The primary disadvantage is that installing via source is not nearly as user-friendly as installing via rpm. Instead of having a nice-and-neat front end to all the installation commands, you must opt for the command line to configure, build, and install the package. This also can cause headaches when a very cryptic error occurs or you have to handedit a Makefile or configuration file before running ./config.

The advantages of installing via source should make this type of installation much more appealing to system administrators (especially in larger corporations). By installing with source code, you are getting a package that is specifically built upon your technology. Because of this, you will have an installed application that is optimized for your environment so it may run faster and smoother and be more stable. This becomes critical in database installations, server installations, number crunching, and graphics manipulation.

The final advantage to using source is that you can quickly open up the code and make any changes necessary for your installation. This can be done with rpm packages, but they have to be taken apart, edited, and put back together.

Types of files to use
File name
Throughout this article you will notice a file called application_name. This is used as an example name. You will need to substitute the name of the file you are actually working with for application_name.

When installing with source, you will be downloading source code that has been tar'dand zipped. Unlike rpm files, source files do not always follow a standard naming convention. Possible file names will end in:
  • .tar
    This is the standard tar archive with no compression.
  • .tgz
    This is a tar file with the standard gzip compression added.
  • .tar.gz
    This is a different naming convention for a tar file with the standard gzip compression added.
  • .bin
    This is a tar archive that contains binary executables rather than source.
  • .bz2
    This is a tar archive compressed with the bz2 compression tool.

For any of the items in the above list, you may (depending on the type of file) have to take a certain number of steps that will require:
  • Decompressing the archive.
  • Unpacking the archive.
  • Creating a Makefile.
  • Building the source.
  • Installing the source.

Although the above list might seem a bit harrowing, fear not. In most cases, the author of the application has created scripts that make the process much easier. Here is a detailed discussion of each of these steps.

Where do you put the file?
This is a good question and one that has many camps. One camp believes that source files should be placed in the /tmp directory. Once you install the files from that directory, they will eventually be deleted by the system. Another camp says that tar source should be compiled and installed in /usr/local. By placing this directory in your users’ $PATH, you make the executable binaries globally available. Still another camp (and the one that I subscribe to) believes that the application source should be compiled and installed from within the /usr/local/src directory. By using this directory, you gain the benefits of the /usr/local directory but also keep a cleaner directory structure, and nothing can possibly overwrite a critical directory (such as the bin directory in /usr/local). For the purposes of this article, I will be placing the zipped and tar'd files into /usr/local/src and then deleting the source files when I am finished.

Decompressing the archive
As I mentioned above, the type of archive you are working on will determine how you move forward in the decompression process. In the world of Windows, tools like WinZip use the standard GUI to perform the compressing and decompressing of these types of files. Linux, of course, has a number of GUIs that will complete this same task (kArchiver and File Roller, to name two), but for the installation of software, I always suggest using the good ol' command line. So let's take a look at decompressing each file type.

You do not actually decompress a file with an extension of .tar for this file type. Instead, you only need to unpack the contents of the archive. (I'll address that in detail in a moment.) If you are working with a .tar.gz (or .tgz type), you need to run the gunzip tool on the file. So by running gunzip application_name.tar.gz (or gunzip application_name.tgz), you will decompress the file and the end result will be a file with a .tar file extension.

Typically, .bin files can be either compressed or not. You’ll just have to guess as to whether you can safely run the above command (gunzip application_name.bin) on the file. If you get an error saying something to the tune of File not in gzipped format, you’ll know that you are not dealing with a compressed archive and you can skip to the next step.

For the bz2 extension, you need to alter your command a bit. Instead of using the standard gzip compression utility, a .bz2 file has been compressed with the bz compression tool. In order to decompress this file type, you will run the command bunzip2 application_name.bz2 and your tar file will decompress.

Unpacking the archive
With the file decompressed, the next step is to unpack (or untar) the archive. This step is done with the tar utility. While the tar command-line utility is a very complex tool, it does have this basic syntax:
tar [options] filename

The standard unpacking options are shown in Table 1 below.

Table 1
Option Description
-c Create a new archive
-d Delete from the archive
-t List the contents of the archive
-x Extract files from the archive
-v Print verbose output while unpacking
-f Use archive file
In most cases, this step will be the same. In order to unpack a tar'd archive, you will issue the following command:
tar vxf archive_name

The above command tells the tar utility to verbosely extract the filearchive_name. From this unpacking, a new directory called, not surprisingly, archive_name will be created.

A shortcut
For files ending in either .tgz or .tar.gz, you can run both the decompressing and unpacking commands in one fell swoop by adding the z option. This option will either uncompress or compress, depending on whether you are creating an archive, in which case it will compress, or unpacking an archive, in which case it will decompress. This shortcut will look like tar xvzf application_name.tgz or tar xvzf application_name.tar.gz.
A word of caution
Some application authors are lazy coders and fail to create a directory within the tar'd directory. If this is the case, when you unpack the tar file, the entire contents of the tar will explode into your working directory. If you're really particular about directory clutter, you will want to create a directory in which to unpack the tar.

Configuring the application
This is where things tend to go a little awry. This particular configuration may not be what you think it is. The configuration step, during the source installation, actually takes parameters specific to your system and creates a Make file that will be used in the compilation of the application.

This step is generally taken with the command (issued from within the source directory) ./configure. Of course, it's not always that simple. Many times, an application, when installed via source, will need to be told where a specific library path is, where a dependency application is located, what user identification (UID) or group identification (GID) to use, and so on. At this point, each application takes on its own life and the only way to be sure of what you are doing is to read the proper Help file. Typically, the programmer will include two different text files that will help in the installation of the application. The first file is the README file. This file will provide the background and the uses of the application (as well as where to turn to for help). The second file, traditionally named INSTALL, will detail the specifics on what parameters need to be sent along with the configure command. Read these files very carefully so you won’t wind up with an installed application that won't run.

That was a word to the wise. Typically, just running ./configure, without arguments, will do the trick. But read the INSTALL file just in case.

Compiling and installing the application
From within the same directory that ran the configure command, you will issue the make command. The make command determines which pieces of the application need to be recompiled and then does so. Generally speaking, this is done without the help of any arguments and is handled by issuing the command make.

Depending on the size of the application, the make can take quite some time. Once the make command finishes its run, you will install the application by issuing the make install command. Once make install has completed its run, the proper executable binaries will be created and either installed into a global directory (like /usr/bin) or into the directory from which you compiled and installed the file. If the latter is true, then you should be able to move that newly created executable to a directory in the users’ $PATH (i.e. /usr/bin) and then delete the contents within application_name (as well as the directory itself).

cp before mv
Usually, if I think I can delete the contents of the applications source directory and I have an executable binary to move, I will copy that binary to its destination, test to see if the application works properly, and then remove the source folder.

After installing via source, you will have an application created specifically for your system. With this type of installation, you can tweak and hone the app to meet your needs. It may take some getting used to, but once you start installing in this manner, the other installation methods will look less and less like viable options.

About Jack Wallen

Jack Wallen is an award-winning writer for TechRepublic and He’s an avid promoter of open source and the voice of The Android Expert. For more news about Jack Wallen, visit his website

Editor's Picks