The packages that are installed in this book are only the tip of the iceberg. We hope that the experience you gained with the LFS book and the BLFS book will give you the background needed to compile, install and configure packages that are not included in this book.
When you want to install a package to a location other than
/usr, you are installing outside the default
environment settings on most machines. The following examples should
assist you in determining how to correct this situation. The examples
cover the complete range of settings that may need updating, but they
are not all needed in every situation.
PATH to include
root to include
/etc/ld.so.conf or expand
LD_LIBRARY_PATH to include it. Before using the
latter option, check out http://xahlee.org/UnixResource_dir/_/ldpath.html.
If you modify
remember to update
/etc/ld.so.cache by executing ldconfig as the
/etc/man_db.conf or expand
PKG_CONFIG_PATH. Some packages are
.pc files in
$PREFIX/share/pkgconfig, so you
may have to include this directory also.
CPPFLAGS when compiling packages
that depend on the package you installed.
LDFLAGS when compiling packages that depend on a
library installed by the package.
If you are in search of a package that is not in the book, the following are different ways you can search for the desired package.
If you know the name of the package, then search Freecode for
it at http://freecode.com/. Also search
Google at http://google.com/. Sometimes a search
rpm at http://rpmfind.net/ or the
deb at http://www.debian.org/distrib/packages#search_packages
can also lead to a link to the package.
If you know the name of the executable, but not the package that the executable belongs to, first try a Google search with the name of the executable. If the results are overwhelming, try searching for the given executable in the Debian repository at http://www.debian.org/distrib/packages#search_contents.
Some general hints on handling new packages:
Many of the newer packages follow the ./configure && make && make install process. Help on the options accepted by configure can be obtained via the command ./configure --help.
Most of the packages contain documentation on compiling and installing the package. Some of the documents are excellent, some not so excellent. Check out the homepage of the package for any additional and updated hints for compiling and configuring the package.
If you are having a problem compiling the package, try searching the LFS archives at http://www.linuxfromscratch.org/search.html for the error or if that fails, try searching Google. Often, a distribution will have already solved the problem (many of them use development versions of packages, so they see the changes sooner than those of us who normally use stable released versions). But be cautious - all builders tend to carry patches which are no longer necessary, and to have fixes which are only required because of their particular choices in how they build a package. You may have to search deeply to find a fix for the package version you are trying to use, or even to find the package (names are sometimes not what you might expect, e.g. ghostscript often has a prefix or a suffix in its name), but the following notes might help:
- enter the package name in the 'Keywords' box, select
the package name, select one of the 'SVN Entries' fields,
then select the
see how they build this package, or look at any patches.
(use your country's version if there is one) - the source
will be in .tar.gz tarballs (either the original upstream
.orig source, or else a
dfsg containing those parts
which comply with debian's free software guidelines)
accompanied by versioned .diff.gz or .tar.gz additions.
These additions often show how the package is built, and
may contain patches. In the .diff.gz versions, any
patches create files in
Fedora http://pkgs.fedoraproject.org/cgit/ - this site is still occasionally overloaded, and somewhat hard to navigate (nearly 300 pages, linked by number) but it is an easy way of looking at .spec files and patches. If you know their name for the package (e.g. mesa.git) you can append that to the URI to get to it. If unavailable, try looking for a local mirror of ftp.fedora.com (the primary site is usually unavailable if fedora cgit is not responding) and download a source rpm to see what they do.
Gentoo - the mirrors for ebuilds and patches seem to be
well-hidden, and they change frequently. Also, if you
have found a mirror, you need to know which directory the
application has been assigned to. The ebuilds themselves
can be found at http://packages.gentoo.org/
- use the search field. If there are any patches, a
mirror will have them in the
files/ directory. Depending on your
browser, or the mirror, you might need to download the
ebuild to be able to read it. Treat the ebuild as a sort
of pseudo-code / shell combination - look in particular
commands and patches, or hazard a guess at the meanings
of the functions such as dodoc.
PLD http://cvs.pld-linux.org/cgi-bin/cvsweb/packages/ - another distro which uses rpms, cvsweb provides access to patches and the spec files.
Slackware - the official package browser is currently
broken. The site at http://slackbuilds.org/ has
current and previous versions in their unofficial
repository with links to homepages, downloads, and some
individual files, particularly the
Ubuntu ftp://ftp.ubuntu.com/ubuntu/pool/ - see the debian notes above.
If everything else fails, try the blfs-support mailing-list.
If you have found a package that is only available in
format, there are two small scripts, rpm2targz and deb2targz that are available at
to convert the archives into a simple
You may also find an rpm2cpio script useful. The Perl version in the linux kernel archives at http://lkml.indiana.edu/hypermail/linux/kernel/0210.2/att-0093/01-rpm2cpio works for most source rpms. The rpm2targz script will use an rpm2cpio script or binary if one is on your path. Note that rpm2cpio will unpack a source rpm in the current directory, giving a tarball, a spec file, and perhaps patches or other files.
Last updated on 2013-02-12 00:13:43 +0000