Compiling Software from Source

Not all the software you might want to use is available in rpm packages or in the exact form that you desire. Many complicated programs have options that can only be selected at compile time and many smaller, special-purpose applications only exist as source code. Fedora Core provides all the tools necessary for you to compile source code into binary applications. First, we'll cover building from source rpm files, and then manipulating source rpm files and finally, building from source tarballs.

NOTE

For other software package formats, you can use the File Roller application (found in the Accessories menu) to easily display, browse, read, and extract contents of compressed files, including legacy archives such as tarballs or compressed tar archives (recognized by their .gz or .tgz extensions). Other compressed files, such as those created with the compress command (ending in .Z) or bzip2 files (ending in .bz2), are also supported by File Roller. The File Roller client will also convert compressed archives between gzip and bzip2 formats.

Building RPMS from src.rpm Files

A rule of thumb is that you never build rpms as the root user even though the directories are already set up at /usr/src/redhat as follows:

 # tree /usr/src/redhat /usr/src/redhat |-- BUILD |-- RPMS |   |-- athlon |   |-- i386 |   |-- i486 |   |-- i586 |   |-- i686 |   `-- noarch |-- SOURCES |-- SPECS `-- SRPMS 

Using the mkdir command, re-create this directory tree structure in your home directory; you can name the new directory redhat (or anything you like). You might even want to create a new user just to build rpms and source code. (You can compile without being root; you just can't install the software systemwide as a regular user.)

The configuration information for building rpms is kept in three places:

/usr/lib/rpm/*/macros The systemwide defaults.

/etc/rpm/macros.* Where systemwide changes are kept.

~/.rpmmacros Where user-specific changes are kept.

Because we need to tell rpm that we will not be using the systemwide default build location for our user, we can

 $ echo "%_topdir $HOME/redhat" > $HOME/.rpmmacros 

TIP

Here, we use > instead of >> to blank the file in case there is already content in it. The >> construct appends information to a file.

To select a temporary directory

 $ echo "%_tmppath $HOME/tmp" >> $HOME/.rpmmacros 

To set any compiler optimization flags (here, we are using an Athlon processor as an example), we will use

 $ echo "-o3 -march=athlon" >> $HOME/.rpmmacros 

To rebuild a src.rpm file as a regular user, you would use

 $ rpmbuild --recompile packagename.src.rpm 

After a successful build, you will find the binary file(s) in ~/redhat/RPMS/athlon.

You can install them as root with

 # rpm -Uvh --replacepkgs --replacefiles packagename.rpm 

If the build fails, the error message will point you to a solution (usually a dependency has not been satisfied). You will find that a lot of the packages named with -devel will be needed before you compile from source code. Install the package for the missing dependency and retry the compile.

Working with Source RPM Files

You might want to modify a source package for your own uses such as adding documentation, changing default settings, or patching the source code itself. Fedora Core provides the source code to its distribution in the form of source RPM files. You can access the source code on disks 4 and 5 of the downloadable CD images or obtain them from the Fedora Core FTP site.

TIP

An important part of the RPM file is called the .spec file, a specification file. It tells RPM how to behave with the particular source files during compilation, installation, and erasure.

As an example, we'll use information that was found at http://elektron.its.tudelft.nl/~rbos36/mdkfreetype2.html (the page has now been removed by the author) to modify the freetype2 library provided with Fedora Core in order to enable the bytecode interpreter. The code for the interpreter has been disabled by default because of redistribution licensing concerns that don't affect individual use. Enabling the interpreter will result in improved rendering of the TrueType fonts. We used the file from Red Hat 7.3 as our example, but the source file from FC4 should work as well.

Begin work by first installing the source RPM package with rpm -i. (Note that here we are building as root to follow the example from the web page; you should typically build packages as a regular user.) In our example, obtain the freetype-2.1.9-2.src.rpm and install it with rpm -i. The source code files are placed in /usr/src/redhat/SOURCES.

Copy the source file (it's a compressed tar file) to /tmp, and then cd (change directories) there to unpack and modify it:

 # cp freetype-2.1.9.tar.bz2 /tmp # cd /tmp 

Because it's a .bz2 (BZip2 compressed) tar file, un-tar it with

 # tar xjvf freetype-2.1.9.tar.bz2 

and cd to the new directory:

 # cd freetype-2.1.9 

Using the text editor of your choice, edit the file include/freetype/config/ftoption.h and find the line

 #undef TT_CONFIG_OPTION_BYTECODE_INTERPRETER 

Change it to

 #define TT_CONFIG_OPTION_BYTECODE_INTERPRETER 

Save it and exit the text editor.

Next, re-create the compressed archive:

 # cd /tmp # tar cfj freetype-2.1.9.tar.bz2 ./freetype-2.1.9/ 

Put it back in your source directory:

 # mv freetype-2.1.9.tar.bz2 /usr/src/SOURCES 

Now edit the .spec file in /usr/src/redhat/SPECS to change the line beginning with Release to increment the number found there. (We are changing the version number by doing this, so it will not conflict with the version of the application we will be replacing.) Make any changes to the %description line to describe your changes if you desire, and save the file.

Build the binary RPM with

 # rpmbuild -bb freetype.spec 

During the build process, RPM will detect a patch and ask you about the patch; press y for "yes" to continue.

The new RPMs (actually four of them) are found in /usr/src/redhat/RPMS/i386. We only need the one named freetype-2.1.9; you can install it with rpm -Uvh. (This is why we changed the version number; if we had not, RPM would not upgrade to the "same" version. Had we not changed the version number, we could have forced the installation with the --replacepackages --replacefiles option.)

The font server needs to be restarted to use the new library, so we use the service command as shown in Chapter 14, "Automating Tasks."

 # service xfs restart 

Enjoy your new look provided by better rendering of the fonts.

Compile from Source Tarballs

Compiling applications from source is not that difficult. Most source code is available as compressed source tarballs that is, tar files that have been compressed using gzip or bzip. The compressed files will typically uncompress into a directory containing several files. It's always a good idea to compile source code as a regular user to limit any damage that broken or malicious code might inflict, so create a directory named source in your home directory.

From wherever you downloaded the source tarball, uncompress it into the ~/source directory using the -C option to tar:

 $ tar zxvf packagename.tgz -C  ~/source $ tar zxvf packagename.tar.gz -C  ~/source $ tar jxvf packagename.bz -C  ~/source $ tar jxvf packagename.tar.bz2 -C  ~/source 

If you're not certain what file compression method was used, employ the file command to figure it out:

 $ file packagename 

Now, change directories to ~/source/packagename and look for a file named README, INSTALL, or a similar name. Print the file out if necessary because it will contain specific instructions on how to compile and install the software. Typically, the procedure to compile source code is

 $ ./configure 

which runs a script to check if all dependencies are met and the build environment is correct. Then,

 $ make 

to compile the software. And finally, as root:

 # make install 

If the compile fails, check the error messages for the reason and run

 $ make clean 

before you start again. You can also run

 $ make uninstall 

to remove the software if you do not like it.

An alternative to running make install is a program named CheckInstall, which will produce an rpm file for your installation. This method allows the RPM database to be aware of and keep track of all the files you are installing. See the following sidebar on CheckInstall for more information.

A Handy Software Installation Tool CheckInstall

When you compile applications from source and install them, they won't show up in the RPM database and therefore can't be managed by RPM.

You can provide RPM management for these applications by using a program named CheckInstall. At its simplest, checkinstall is a drop-in substitute for the make install step in building from source code.

For example, when compiling from source code, you would traditionally use

 # ./configure # make # make install 

Using CheckInstall, the steps would look like this:

 # ./configure # make # checkinstall 

CheckInstall will create a binary .rpm package and install the application from it. This makes the new application part of the RPM database. The new .rpm file is left for you in /usr/src/redhat/RPMS/i386. The new application can later be uninstalled with rpm -e.

Some applications arrive in the form of a shell script wrapper. Using the shell script as the argument to CheckInstall will provide a .rpm file of the installed files and add them to your RPM database. Not all applications will install with CheckInstall. Read its accompanying documentation carefully.

CheckInstall can be downloaded from http://asic-linux.com.mx/~izto/checkinstall/index.php.

Relevant Fedora Core and Linux Commands

You'll use these commands while managing your Fedora Core Linux system resources and software packages:

system-config-packages The Fedora Core GUI Package Manager.

rpm The RPM Package Manager.

rpmbuild Builds RPM source and binary packages.