4. Installing Programs from Source Code

Introduction

Even with all the package managers and dependency resolvers out there, there are times when building from sources is preferable. For example, a program you want may not be available in a packaged version, or you may need to control exactly what options and features are built into it, or you may want to optimize it for your architecture. Many experienced administrators recommend building programs critical to security (ssh and all servers, for example) from sources.

When building from sources, be sure to read all the instructions. While the configure-make-make install procedure is fairly standard, there are many exceptions, according to the quirks of the program authors. And there are often many configuration options, which only the documention for the program can tell you.

If you prefer using packages, all the tools are freely available for building your own RPMs and .debs. However, it’s a fair learning curve to learn to use RPM or to build your own .debs. There is a third option: CheckInstall. CheckInstall is a great utility for easily building your own RPM, Debian, or Slackware packages from source code.

4.2. Preparing Your System for Compiling Programs from Sources

Problem

You know you need a compiler and maybe some other utilities to be able to compile programs from sources, but you’re not sure exactly what.

Solution

There are two categories of programs that you will need:

Essential development tools common to all Linux systems
Specific libraries or utilities for whatever program you are compiling

Here is a list of the common Linux development tools:

GNU coreutils: This is a large collection of essential system utilities: shellutils, fileutils, and textutils. See http://www.gnu.org/software/coreutils/ for a complete listing, or info coreutils.
GNU binutils: Utilities for doing things to binary files (http://www.gnu.org/software/binutils/).
gcc: GNU compiler collection, containing C, C++, Objective-C, Fortran, Java, and Ada, and libraries for these languages.
GNU tar: Archiving utility for source tarballs; these end in .tar.
gunzip: Compression utility often paired with tar. These end in .tar.gz.
bunzip2: A super-compression format for packing and unpacking tarballs; these end in .bz2.
make: This does the work of reading your configuration options and building the actual program files.

The documentation for the application you are building will tell you everything that it needs to build successfully.

Discussion

Most Linux distributions have an installation option for “Core Development Tools,” or some such, so you don’t have to hunt down and install them individually.

You’ll need to read the documentation for the application you are building to find out any requirements specific to the program. Look for README, INSTALL, and other documentation in the source tarball. Read everything. When you run the configure script, it will check your system to see if all the required elements are present. If anything is missing, it will exit with errors, and tell what you need.

4.3. Generating a List of Files from a Source Install for Easy Uninstalls

Problem

You need to know what files are installed on your system when you install a program from source code, so that you can find and remove all of them if you decide you don’t want them anymore. Some program authors thoughtfully include a “make uninstall” target to perform a clean uninstall, but many do not.

Solution

You can use standard Linux utilities to generate a pre-installation list of all files on your system. Then generate a post-installation list, and diff the two lists to make a list of newly-installed files. This example uses JOE: Joe’s Own Editor:

# find / | grep -v -e ^/proc/ -e ^/tmp/ -e ^/dev/ > joe-preinstall.list

Compile and install your new program, then generate the post-installation list:

# find / | grep -v -e ^/proc/ -e ^/tmp/ -e ^/dev/ > joe-postinstall.list

Then create a list of files installed by Joe by diffing the two lists:

$ diff joe-preinstall.list joe-postinstall.list > joe-installed.list

Discussion

Using find and grep together makes it easy to exclude directories that don’t matter for your final list. The -v option for grep means “exclude the following,” or “display things that do not match the following expressions.”. -e specifies the pattern to search for. The caret, ^, means “look for the pattern at the beginning of the lines.”

You don’t need to bother with /proc or /tmp files, because these are transient and constantly changing. /dev files are managed by the system, so you can ignore these as well. And it’s also an important safety measure—when you remove a program manually, using your nice diff list, /proc, /tmp, and /dev are all directories you shouldn’t touch in any case.

4.4. Installing Programs from Source Code

Problem

You want to install a program from source code, but you’re having trouble navigating the thickets of tarballs, makefiles, and bunzips.

Solution

Unpack the tarball (compressed archive), then configure, make, and install the program.

Start in the directory where you store your tarballs and source trees. This example uses JOE (Joe’s Own Editor):

               # cd /usr/src/downloads
               # tar zxvf joe-2.9.8.tar.gz
               # cd joe-2.9.8
               # ls
               # less README
               # less INFO
               # ./configure —help
               # ./configure <options, if needed>
               # make
               # make install | tee joe-makeinstall

The last command stores the installation output in the text file joe-makeinstall.

Some programs are archived with the bunzip2 utility, rather than the more traditional gzip. This is how to unpack a .bz2 archive:

               # tar jxvf joe-2.9.8.tar.bz2

To uninstall a source-built program, use:

               # make uninstall

Uninstalling works only if the program author included a make uninstall option. Piping the output of make install to a text file gives you a reference if you have to remove all the files manually. Or generate a list using Recipe Recipe 4.3.

Discussion

The steps described in this section are the standard way of installing programs from source code. However, not all program authors follow the same procedures. Be sure to review all the program documentation first.

Studying your configure options is the most important part. Some programs, like Apache, have dozens of compile-time options. For prudent basic security, you only want to compile in support for things you really need. This is most important on servers that are exposed to untrusted networks, such as web and mail servers.

Good reasons to compile programs from source are:

You can configure exactly the options you need.
You can optimize the program for your architecture.
You have ultimate control over what is installed.

The bad part:

Upgrades and removals can be messy.
Dependency hell is only a short step away.
Compiling a large program can take hours.

Some servers should be built from sources. For example, an Apache web server really needs to be source-built to get full customization and optimization.

For a desktop system, forget it. They’re too big and complex. Use the nice package-based Linux distributions for these.

4.5. Using CheckInstall to Create Packages from Sources

Problem

You want to create Slackware, Red Hat, or Debian packages from source code, because an application that you want to install does not come in the package you want. You have read up on building packages, and it’s very complicated. Isn’t there an easier way?

Solution

Use CheckInstall. Again using Joe’s Own Editor in this example, on Debian, do the following:

               # mkdir /doc-pak
               # tar zxvf joe-2.9.8.tar.gz
# cd joe-2.9.8
# ./configure
               # make
               # checkinstall -D

CheckInstall replaces make install, so it must run from the root of the source tree. Follow the prompts and do what they say. It will build and install a .deb, as we can verify:

               $ dpkg -l | grep joe
ii  joe          2.9.8-1      joe's own editor, my fave

And that’s it. It’s installed and ready to go to work. A copy of the package will remain in the source directory.

To build a Slackware package, use:

               # checkinstall -S

To build an RPM package, use:

               # checkinstall -R

Discussion

The doc-pak directory is where CheckInstall places READMEs and other program documentation. If you don’t create the doc-pak directory, CheckInstall asks if you want to build a default documentation directory. If you say no, your package will have no documentation.

CheckInstall uses the native installation program’s package manager: RPM on Red Hat, installpkg on Slackware, .apt on Debian. To remove a CheckInstall package, simply use your system’s package manager.

CheckInstall supports any install scripts. For example:

               # checkinstall -D make install_packages
               # checkinstall -R make modules_install
               # checkinstall -S install.sh
               # checkinstall -D setup

Remember to study the README of the program you’re installing, and any other included documentation. Not all source packages use the traditional configure-make-make install dance. Some use other installation scripts, as in the example above.

CheckInstall does not yet allow creating a package without automatically installing it, though this may change in future releases.

Linux Cookbook by Carla Schroder

Chapter 4. Installing Programs from Source Code

Introduction

4.2. Preparing Your System for Compiling Programs from Sources

Problem

Solution

Discussion

See Also

4.3. Generating a List of Files from a Source Install for Easy Uninstalls

Problem

Solution

Discussion

See Also

4.4. Installing Programs from Source Code

Problem

Solution

Discussion

See Also

4.5. Using CheckInstall to Create Packages from Sources

Problem

Solution

Discussion

See Also

Don’t leave empty-handed

It’s yours, free.

Check it out now on O’Reilly