Building from Source | Beginning Fedora 2

While RPM is an excellent , feature-rich, technology, it s not used universally , and you may occasionally find yourself needing to deal with uncompiled source packages in Tape Archive (TAR) or other compressed formats. Most of the packages source code is usually available in .tar or .tar.gz format.

Note

A binary package is a precompiled package, and comes ready to install. By contrast, you may also come across source code packages ”these contain uncompiled code, and must be compiled before installation.

A source code is an uncompiled source of the software, which needs to be compiled on a specific platform to be able to install and use.

A TAR file is an archive file created using the TAR command on a Linux system. TAR archives were initially used to store files on magnetic tape but now commonly occur on all storage media.

TAR files are simply a method of sticking a number of smaller files together, so that a collection of files becomes one larger (easier to handle) file. This larger file can then be compressed using a program such as gzip to reduce its size . (This is similar to the way that Windows creates Zip files.)

	RPM Package	Source Code
Ease of use	Very easy to install the software; easy to uninstall the package	Not an easy process because software source code needs to be compiled. Not easy to uninstall the package because it is difficult to find out the installation path of files and dependencies.
Usability	Limited to platforms such as Fedora, Red Hat Enterprise Linux, and so on	Widely used. Source code is available for all the open source platforms.
Management	Keeps track of package files and dependencies.	Difficult to keep track of the files and dependencies.
Flexibility	Less flexible. The package installation paths are predefined and have limited functionality to alter them.	Flexible. Packages can be compiled and installed anywhere on the system.
Control	Limited control-of-build process and installation.	High control-of-build process and installation.

Most of the applications are widely available in RPM package format and compressed source code format; many are only available in source code format. If the application is available in RPM as well as source code format, the one you choose depends on your personal preference.

It is always better to learn how to compile the source code into an installable application, in case it is only available in the source code format. In most cases, the applications source code is available before they are ported to the rpm package. This gives you the advantage of upgrading to the latest version of the application.

In the next section, you download, compile, and install WGET, a utility to download files from the Internet. Fedora comes with the wget application, and you do not have to worry about compiling it from the source code. However, if you learn how to build an application from source code, you can update to the latest version of an application when it becomes available.

Installing Development Tools

Fedora comes with a set of development tools, which must be installed before you can compile any other application on the system. You must install the set of development tools, such as gcc, make, and Perl, to compile the source code on the system.

We will use the RPM Package Management applet to install development tools.

Try It Out Installing the Development Tools

Launch the RPM Package Management Tool by executing the command system-config-packages at the command prompt.

You will get an Add and Remove Software graphical interface. Browse through the entire package category until you find the Development category. Select the Development Tools package group by clicking Details, and then press the Install Packages button. It includes all the packages such as gcc, make, and so on required for building the applications from source (see Figure 8-14).

Figure 8-14

The Update process takes some time, but once finished, you can come out of the Package Management window and start building applications from source.

Building the Application

You will build a wget application as an exercise. You will download the source code, and compile and install the wget application. The entire process incorporates all the information you need to build any other application from source code.

Building an application from source code consists of many steps; the following steps are particularly important:

Downloading the source code
Configuring the source code
Compiling the source code
Installing the compiled application

Try It Out Building the wget Application

To help you understand the process of building an application from source code, we will walk through the installation of a wget application, which is a non-interactive command line utility to retrieve files using HTTP, HTTPS, and FTP protocols.

The first step to build an application is to find a suitable directory in which to store the source code. The preferred choice is to use the /usr/local/src directory because it is separate from other operating system installation directories and can be used safely. You can also choose any other directory that is suitable to your operating system environment.

After you have decided the root source code directory, you should create a subdirectory where you can unpack the source code package. Some applications packages create their own directory to store source code files when unpacked, whereas others just dump the files in the current directory. So, let s create a subdirectory, wget , within the /usr/local/src directory.

   # mkdir /usr/local/src/wget

Now you can change to the /usr/local/src/wget directory and download the wget application source code from http://ftp.gnu.org/pub/gnu/wget/wget-1.9.1.tar.gz .

You can download an application using your browser or from the command line using the preinstalled wget RPM package:

   # mkdir /usr/local/src/wget     # cd /usr/local/src/wget# /usr/bin/wget http://ftp.gnu.org/pub/gnu/wget/wget-1.9.1.tar.gz     --03:35:01--  http://ftp.gnu.org/pub/gnu/wget/wget-1.9.1.tar.gz     => `wget-1.9.1.tar.gz'     Resolving ftp.gnu.org... 199.232.41.7     Connecting to ftp.gnu.org[199.232.41.7]:80... connected.     HTTP request sent, awaiting response... 200 OK     Length: 1,322,378 [application/x-tar]         100%[====================================>] 1,322,378     48.57K/s    ETA 00:00         03:35:28 (49.81 KB/s) - `wget-1.9.1.tar.gz' saved [1322378/1322378]

The next step is to uncompress the wget application source code s TAR archive.

   # tar -kzxvf wget-1.9.1.tar.gzwget-1.9.1/     wget-1.9.1/doc/     wget-1.9.1/doc/ChangeLog-branches/     wget-1.9.1/doc/ChangeLog-branches/1.6_branch.ChangeLog     wget-1.9.1/doc/ChangeLog     wget-1.9.1/doc/Makefile.in.....wget-1.9.1/ltmain.sh     wget-1.9.1/mkinstalldirs     wget-1.9.1/stamp-h.in

You must have noticed the various options used with the tar command to uncompress the TAR archive. Let s go through each option:

The k switch forces the TAR not to overwrite the old files. This ensures that if there are any files with the same name already on the system, TAR will keep the old files as they are and not overwrite them. This is a safety measure to protect important files from a rogue package designed to destroy existing files on the system.
The z switch filters the archive through gzip . It uncompresses the compressed TAR archive and makes it a normal TAR archive.
The x switch extracts the files from the TAR archive.
The v option is to verbosely list the files processed from the TAR archive.
The f option specifies the TAR archive to use.

You now you have a directory, wget-1.9.1 , which contains all the wget source code. You can now start the compilation process. Let s change to the wget-1.9.1 directory and run the configure program, which configures the source code ready to be built on the system.

   # cd wget-1.9.1# ./configure --prefix=/usr/localconfiguring for GNU Wget 1.9.1     checking build system type... i686-pc-linux-gnu     checking host system type... i686-pc-linux-gnu     checking whether make sets $(MAKE)... yes     checking for a BSD-compatible install... /usr/bin/install -c     checking for gcc... gcc......config.status: creating src/config.h     config.status: executing default commands     generating po/POTFILES from ./po/POTFILES.in     creating po/Makefile

We executed the configure command with the prefix option to configure the source code. As shown, the configure script finds out the platform and operating system availability of compilers, tools, and libraries on the system where we are building the application. It also creates a Makefile, which will be used by the make command to compile the source code.

The -prefix option specifies a directory where the application files will be installed. It is good practice to specify the “prefix option with a directory to control where the custom build software will be installed. You can also run the configure script without specifying any option, and the script will use all the default options. We have specified /usr/local as the application install directory; all the files are installed under the /usr/local directory for better control. You can also specify any suitable path or directory with the “prefix option to install the application files.

Caution

You should always read INSTALL and README files supplied with the application before you start building the application. They will provide you with a better understanding of an application s features and build options.

Now let s actually compile the source code by executing the make command to build the application.

   # makeecho timestamp > stamp-h.in     cd src && make CC='gcc' CPPFLAGS='' DEFS='-DHAVE_CONFIG_H -DSYSTEM_WGETRC=\"/usr/local/etc/wgetrc\" -DLOCALEDIR=\"/usr/local/share/locale\"' CFLAGS='-O2 -Wall -Wno-implicit' LDFLAGS='' LIBS='-lssl -lcrypto -ldl ' prefix='/usr/local' exec_prefix='/usr/local' bindir='/usr/local/bin' infodir='/usr/local/info' mandir='/usr/local/man' manext='1'     make[1]: Entering directory `/usr/local/src/wget-1.9.1/src'     gcc -I. -I.    -DHAVE_CONFIG_H -DSYSTEM_WGETRC=\"/usr/local/etc/wgetrc\" -DLOCALEDIR=\"/usr/local/share/locale\" -O2 -Wall -Wno-implicit -c cmpt.c.........make[1]: Entering directory '/usr/local/src/wget-1.9.1/util'     make[1]: Nothing to be done for `all'.     make[1]: Leaving directory `/usr/local/src/wget-1.9.1/util'     cd windows && make CC='gcc' CPPFLAGS='' DEFS='-DHAVE_CONFIG_H -DSYSTEM_WGETRC=\"/usr/local/etc/wgetrc\" -DLOCALEDIR=\"/usr/local/share/locale\"' CFLAGS='-O2 -Wall -Wno-implicit' LDFLAGS='' LIBS='-lssl -lcrypto -ldl ' prefix='/usr/local' exec_prefix='/usr/local' bindir='/usr/local/bin' infodir='/usr/local/info' mandir='/usr/local/man' manext='1'     make[1]: Entering directory `/usr/local/src/wget-1.9.1/windows'     make[1]: Nothing to be done for `all'.     make[1]: Leaving directory `/usr/local/src/wget-1.9.1/windows'

The make command follows the instruction in Makefile, which was created by the configure script in the previous step, to build the source code. The make command will finish compiling the source code after a few minutes depending on the number of source files. The application will be ready, with all binaries, to be installed on the system.

Finally, install the compiled application into the /usr/local/ directory:

   # make install     cd src && make CC='gcc' CPPFLAGS='' DEFS='-DHAVE_CONFIG_H -DSYSTEM_WGETRC=\"/usr/local//etc/wgetrc\" -DLOCALEDIR=\"/usr/local//share/locale\"' CFLAGS='-O2 -Wall -Wno-implicit' LDFLAGS='' LIBS='-lssl -lcrypto -ldl ' prefix='/usr/local/' exec_prefix='/usr/local/' bindir='/usr/local//bin' infodir='/usr/local//info' mandir='/usr/local//man' manext='1' install.bin     make[1]: Entering directory `/usr/local/src/wget-1.9.1/src'     ../mkinstalldirs /usr/local//bin     /usr/bin/install -c wget /usr/local//bin/wget     make[1]: Leaving directory `/usr/local/src/wget-1.9.1/src'......make[1]: Leaving directory `/usr/local/src/wget-1.9.1/po'     cd doc && make CC='gcc' CPPFLAGS='' DEFS='-DHAVE_CONFIG_H -DSYSTEM_WGETRC=\"/usr/local//etc/wgetrc\" -DLOCALEDIR=\"/usr/local//share/locale\"' CFLAGS='-O2 -Wall -Wno-implicit' LDFLAGS='' LIBS='-lssl -lcrypto -ldl ' prefix='/usr/local/' exec_prefix='/usr/local/' bindir='/usr/local//bin' infodir='/usr/local//info' mandir='/usr/local//man' manext='1' install.man     make[1]: Entering directory `/usr/local/src/wget-1.9.1/doc'     ../mkinstalldirs /usr/local//man/man1     /usr/bin/install -c -m 644 wget.1 /usr/local//man/man1/wget.1     make[1]: Leaving directory `/usr/local/src/wget-1.9.1/doc'

Following the preceding steps, you will now have the wget application installed under /usr/local directories. You will be able to execute the compiled wget application from the /usr/local/bin directory.

Let s check the wget application to see if it has been built and installed properly. You will find the wget binary executable under the /usr/local/bin directory because we specified this directory while configuring the source code. You can execute wget with the switch “version to verify that it is version 1.9.

   $ /usr/local/bin/wget versionGNU Wget 1.9.1         Copyright (C) 2003 Free Software Foundation, Inc.     This program is distributed in the hope that it will be useful,     but WITHOUT ANY WARRANTY; without even the implied warranty of     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the     GNU General Public License for more details.         Originally written by Hrvoje Niksic <hniksic@xemacs.org>.

The existing wget application will continue to exist on your system in its original location (that is, /usr/bin ). You can check the version of the original wget application as follows:

   $ /usr/bin/wget version     GNU Wget 1.9+cvs-stable (Red Hat modified)         Copyright (C) 2003 Free Software Foundation, Inc.     This program is distributed in the hope that it will be useful,     but WITHOUT ANY WARRANTY; without even the implied warranty of     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the     GNU General Public License for more details.         Originally written by Hrvoje Niksic <hniksic@xemacs.org>.

It is your choice whether to keep both versions of an application. Typically, when you install a new version of an application, you should keep the old version until you have tested the new version for some time. That way, you can easily revert back to the old version of the application if something goes wrong with the new version.

How it works

Finally, you have built your first application from source code. Building an application from source code is usually a straightforward process, but it varies from application to application:

   # ./configure --prefix=/path/to/some/dir     # make     # make install

The preceding three commands build the source code as follows.

The first command, ./configure “prefix=/path/to/some/dir , finds out the platform, operating system, and development tools on your system, and also creates a Makefile, which the make command uses to compile the source code.
The second command, make , compiles the source code. It follows the instruction in Makefile.
The third command, make install , installs the binary application under the directory specified while executing the configure command (--prefix directory).

Building applications from source code gives you more control over the entire application building process, a choice to modify or optimize the source code, and also to select where to install the application. The process of building source code is generally straightforward, but you can run into source code compile problems. It is beyond the scope of this book to discuss these various situations, so please refer to Beginning Linux Programming, by Richard Stones, et al from Wrox Press for more details.