Skip to main content

The Extract and Build Five-Step

The vast majority of source packages can be built using what I call the extract and build five-step. If you read my books or any of my columns at Linux Journal, UnixReview, InformIT, and others, you'll have seen me use that expression more than once. If we wanted to get really picky, I suppose that step one could also involve the downloading of the software, but I'll pretend you've already found and downloaded something, a hypothetical little package called ftl-travel, and you are now anxious to take it for a ride. I'll give you the five steps, then I will discuss them in more detail.

tar -xzvf ftl-travel-2.1.tar.gz
cd ftl-travel-2.1
./configure
make
su -c "make install"

Easy, isn't it? Now you can just type ftl-travel from the command prompt and be on your way. Now that I've given you a really short version of things, let me give you some additional details about what each of these steps mean.

Step 1: Unpacking the Archive

Most program sources are distributed as tarballs, meaning that they have been stored using the tar archiving command. In the name above (ftl-travel-2.1.tar.gz) the ftl-travel part of it is the name of the program itself. The 2.1 represents the version number of the package, and the tar.gz tells us that this package is archived using the tar command and compressed using the gzip command.

You can, therefore, extract the archive with the command:

tar -xzvf ftl-travel-2.1.tar.gz

The x means extract. The z tells the tar command to use the gunzip command to extract. The v says that tar should show us a list of the files it is extracting—in other words, be verbose. Finally, the f identifies the file itself, the one you just downloaded.

Sometimes the extension .tar.gz will be shortened to .tgz. There are a few other extensions in use out there. For instance, the package may have a .tar.Z extension instead, meaning that the file has been compressed using the compress command. To extract the source from this tarball, you first uncompress the file using the uncompress command. Then you continue with your tar extract:

uncompress ftl-travel-2.1.tar.Z
tar -xvf ftp-travel-2.1.tar

To make life even easier, you could also just shorten the whole thing to:

tar -xZvf filename.tar.Z

Every once in a while (if the package is very large), the extension will be .bz2, otherwise known as a bzip2 archive. To open this one, you perform essentially the same steps you did with compress. Use the command:

bunzip2 ftl-drive-1.01.tar.bz2

to uncompress the file, then extract using the standard tar command.

Steps 2–5: Building Your Programs

Once you have extracted the program source from the tar archive, change directory to the software’s distribution directory. That's step 2. Using my current ftl-travel example, type cd ftl-travel-2.1. From there, I build and install my software, like this.

./configure
make
su -c "make install"

Most programmers will include a configure script but if it is missing, make sure you read the README and INSTALL files provided in the installation directory.

The ./configure step builds what is called a Makefile. The Makefile is used by the next command, make. In building the Makefile, the configure step collects information about your system and determines what needs to be compiled or recompiled in order to build your software. This brings us to the next step, which is to type make. You’ll see a lot of information going by on your screen as programs are compiled and linked. Usually (after a successful compile), you follow the make command by typing su -c "make install". This will copy the software into the directories defined in the Makefile.

The reason that I have you type su -c "make install" is because the final step of an installation usually needs to be done by the root user. Because we don't want to be running as root on a regular basis (for security reasons), the su -c step lets us quickly jump into root user mode for one command (where you will be prompted for the root password) and just as quickly jump back out.

A number of programmers also provide a make uninstall option, should you decide that you do not want to keep the program around. By the way, if you are an open source programmer (or plan to be one) and you want to make people happy, always provide an uninstall option.

README, Please!

If you are like me, you tend to want to just install and run that software, which is partly why I jumped ahead a bit and skipped a very important step. You generally do not have to do this because 95% of installs are the same, but . . . just before you go ahead with your final three steps, you should consider pausing in the source directory and typing ls to list the files in the directory. What you would see are numerous files, something like this:

CHANGES README Makefile Makefile.in configure
INSTALL ftl-travel.h ftl-travel.c engine.c config.h

The first thing you want to do is read any README and INSTALL files. The next step is almost always going to be the ./configure step I mentioned as part of my extract and build the five-step, but there may be details you want to know about in those files. There may also be some prerequisites that you should know about or some personal options that you may want to set. It takes only a few minutes, and it may be extremely useful.

. . . and that, my friends, covers almost everything you need to know about installing software from source.

-- Marcel Gagné

A few flourishes to the quickstep

Having installed a lot of software from source, I've learned a few basic variations of the quickstep. My favourite variation goes like this:

  1. Reposition to a good directory for source code: cd /usr/local/src
    /usr/local/src has the advantage of being meant to be the place you put the source code for your locally installed-from-source programs, and having a standard place for these things means that you know where to find them when you need to upgrade or recompile.
  2. Unpack the tarball: tar -xzvf ftl-travel-2.1.tar.gz
  3. Read the README and INSTALL documentation. INSTALL is usually the place where you find all the hints on how to properly install the software, what dependancies it has, and what options you should use for the ./configure step
  4. Configure: ./configure --prefix=/usr/local --sysconfdir=/etc --localstatedir=/var
    This does three things: it ensures that the binary and man pages are put in the /usr/local directory tree, rather than the /usr or / directory tree, it ensures that any system configuration files wind up in /etc rather than /usr/local/etc, and it ensures that any log or lock files wind up in the /var directory tree rather than the /usr/local/var directory tree. This puts all the extra files exactly where I expect to find them, along with other files of similar purpose and type.
  5. make clean && make && make check
    Clean up any stray bits from previous make attempts, then make the new application, then run any tests that the author has included.
  6. (Optional) su -c "chown -R bin.bin ."
    I like all my installed applications to have a single owner, rather than the random uid that comes with the package. Here, bin.bin is a convenience; for some packages this will be root.root or root.wheel.
  7. su -c "checkinstall"
    checkinstall is a neat application that runs the "make install" for you. It performs a fake install, records the results, and then packages the installed files into a native install package (RedHat RPM, Debian DEB, or Slackware TGZ) and installs the package. The advantage here is that you now have the full use of your native package management tools to deinstall or upgrade the application, rather than having to fiddle with make uninstall (if it exists).

--
Lew Pitcher

Master Codewright & JOAT-in-training
Registered Linux User #112576 (http://counter.li.org/)
Slackware - Because I know what I'm doing.

Post new comment

CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.