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 provides all the tools necessary for you to compile source code into binary applications. First, we 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 FilesA 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:
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.rpmAfter 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.rpmIf the build fails, the error message points you to a solution (usually a dependency has not been satisfied). You will find that a lot of the packages named with -devel are needed before you compile from source code. Install the package for the missing dependency and retry the compile. Working with Source RPM FilesYou 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 the Fedora FTP site. Tip An important part of the RPM file is 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 will 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 in order to enable the bytecode interpreter. The code for the interpreter has been disabled by default because of redistribution licensing concerns that do not affect individual use. Enabling the interpreter will result in improved rendering of the TrueType fonts. We use the file from Red Hat 7.3 as our example, but the source file from FC5 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 is 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 is a .bz2 (BZip2 compressed) tar file, untar 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_INTERPRETERSave 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; type y for "yes" to continue. The new RPMs (actually four of them) are found in /usr/src/redhat/RPMS/i386. We need only 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 15, "Automating Tasks." # service xfs restart Enjoy your new lookprovided by better rendering of the fonts. Compile from Source TarballsCompiling applications from source is not that difficult. Most source code is available as compressed source tarballsthat is, tar files that have been compressed using gzip or bzip. The compressed files typically uncompress into a directory containing several files. It is 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 are 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 out the file if necessary because it contains 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, run # 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 produces 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.
|
EAN: 2147483647
Pages: 362