Notes for Building Software

We begin by summarizing how our Linux distribution was built. This should give you a better feel for how the various parts of a distribution fit together.

  1. There are three general "models" for software distribution:

  2. To build a Linux system, you need a pre-existing system with (minimally) the following software:

    And if you want to run the tests on binutils and gcc (which are highly recommended), you need

    All versions of all installed software must be inter-operable.

    This is a highly nontrivial exercise. Creating a Linux distribution involves a great deal of effort in verifying inter-operability. This is a major contribution of the Linux From Scratch project. In general, you must read the README files associated with each package to determine which versions of other packages are required for correct operation.

  3. Being able to build a Linux system is one thing; being able to run one is another. To have an operating build environment you must build and install:

    and you must create a number of directories and files:

  4. Now that you have an operating build system, your first step is to re-build all of the above software. This verifies the integrity of your build environment. Then you need to add the software that makes it a usable UNIX environment.

    A usable Linux system includes the following additional packages:

  5. Finally, a modern Linux system should include the following software (and of course, their dependencies):

    And of course anything you need to enjoy your system. Since a Linux system is expected to grow as your needs do, it is always a good idea to build as many libraries as you can, so that when you want to install a new piece of software, it is likely that you have the libraries it requires. A complete list of the commands used to install the software in our distribution is in /root/lfs-6.2.in, /root/blfs-6.2.in and /root/postlfs.in.

  6. One of the most important things to do before building new software is to have a good backup. While most software builds are bug-free, it is always possible, especially during the installation phase, that a faulty install script might modify or remove files used by other packages.

  7. Software builds usually include the following steps, although depending on the package, one or more may be omitted or replaced. Always read the INSTALL file to make sure you are installing the software correctly!

    1. Download and un-tar the software.

    2. cd to the software directory.

    3. Install any required patches.

    4. ./configure - this performs a thorough check of the current system capabilities, including what software is already installed, and configures the build process accordingly. If a package requires or optionally uses other software, that software must be installed before configure will find it. Sometimes it needs a little help... Use ./configure --help to list all of the configuration options available for this package.

      Note that configure will determine your CPU type and build the software for that processor. Since not all processors have the same capabilities, you should build the software on the same type of CPU, or a lower class of compatible CPU, that you intend to run it on. For instance, software built on a Pentium will run on any class of Pentium, but software built on a Pentium II will only run on a Pentium II or better. It is possible to build for a different processor, but that is outside the scope of this class.

      Be sure to check the output of configure to make sure the package will be built to your needs; some of these builds are LONG!

    5. make (sometimes more than one, with various parameters)

    6. make install (which must be done as root, on a writable filesystem).

    7. Create post-installation configuration files.

    It is a good idea to keep a record of exactly which commands were used to build each package, and a log of the build output. This can be done as follows:
    (./configure) 2>&1 | tee package.log

    (make && make install) 2>&1 | tee -a package.log

    The "2>&1" will redirect stderr to stdout, and the tee will allow you to see the output as it is written to the log file (the "-a" tells tee to append to the log file). The "&&" ensures that the "make install" will not run if the "make" fails. Of course, you should not do either if there were problems with the configure.

  8. Most packages make use of the shared libraries (".so" files). You can build statically-linked software, in which the required library routines are copied into the executable program, if you intend for the software to be used on a system which may not have the required libraries available. This makes the executables very big.

    If you install software which includes new libraries, the install process will use ldconfig to rebuild the runtime linkages. /etc/ld.so.conf contains a list of the directories in which the dynamic loader is to look for libraries. Any library directories other than /lib and /usr/lib must be included in /etc/ld.so.conf. ldd can be used to determine which libraries are required by a given program.

  9. If you are running short on disk space, you can reduce the size of binary executables and libraries using
    strip --strip-debug (library file name)

    strip --strip-unneeded (binary executable file name)

    Be sure NOT to do the latter on libraries!

  10. During the build of our distribution, several additional parameters and steps were performed:

    A number of small configuration changes and fixes were made; see the comments in /root/lfs-6.2.in, /root/blfs-6.2.in and /root/postlfs.in.

  11. EXERCISES for Building Software:

    1. Test mplayer by playing a CD (mplayer cdda://1) and listening to Internet Radio (mplayer -playlist http://cpr.streamguys.net/wvxu.pls).

    2. You can burn a data CD using the commands 
      mkisofs -l -R -allow-leading-dots -o output.iso (input directory)
cdrecord -v dev=/dev/sg1 -data output.iso
      The mkisofs creates an ISO-9660 filesystem in the file output.iso, which is then burned using cdrecord.

      To burn a music CD, simply cd to a directory with wav files to be burned (make sure they will fit!), and 

      cdrecord -v dev=/dev/sg1 driveropts=burnfree -audio -pad *.wav

    3. To burn a data DVD, do the mkisofs as for the data CD. Then 
      growisofs -dvd-compat -Z /dev/sr0=output.iso
      Making video DVDs are, alas, outside the scope of this course.

      If you have blank DVDs which are rated at a speed slower than your burner, you will want to include the option -speed=1 to force the speed to a lower value (it won't actually burn at 1X, but it should burn slowly enough to work).

    4. Use ldd to find out which libraries are required by login, bash and seamonkey (check all running seamonkey executables).

    5. Follow the BLFS instructions to install HTML Tidy. Be sure to test it!

©2012, Kenneth R. Koehler. All Rights Reserved. This document may be freely reproduced provided that this copyright notice is included.

Please send comments or suggestions to the author.