In this chapter, we enter the building site and start constructing the LFS system in earnest. That is, we chroot into the temporary mini Linux system, make a few final preparations, and then begin installing the packages.
The installation of this software is straightforward. Although in many cases the installation instructions could be made shorter and more generic, we have opted to provide the full instructions for every package to minimize the possibilities for mistakes. The key to learning what makes a Linux system work is to know what each package is used for and why you (or the system) may need it.
        We do not recommend using optimizations. They can make a program run
        slightly faster, but they may also cause compilation difficulties and
        problems when running the program. If a package refuses to compile
        when using optimization, try to compile it without optimization and
        see if that fixes the problem. Even if the package does compile when
        using optimization, there is the risk it may have been compiled
        incorrectly because of the complex interactions between the code and
        build tools. Also note that the -march
        and -mtune options using values not
        specified in the book have not been tested. This may cause problems
        with the toolchain packages (Binutils, GCC and Glibc). The small
        potential gains achieved in using compiler optimizations are often
        outweighed by the risks. First-time builders of LFS are encouraged to
        build without custom optimizations. The subsequent system will still
        run very fast and be stable at the same time.
      
        The order that packages are installed in this chapter needs to be
        strictly followed to ensure that no program accidentally acquires a
        path referring to /tools hard-wired
        into it. For the same reason, do not compile separate packages in
        parallel. Compiling in parallel may save time (especially on dual-CPU
        machines), but it could result in a program containing a hard-wired
        path to /tools, which will cause the
        program to stop working when that directory is removed.
      
Before the installation instructions, each installation page provides information about the package, including a concise description of what it contains, approximately how long it will take to build, and how much disk space is required during this building process. Following the installation instructions, there is a list of programs and libraries (along with brief descriptions of these) that the package installs.
![[Note]](../images/note.png) 
        The SBU values and required disk space includes test suite data for all applicable packages in Chapter 6.
In general, the LFS editors discourage building and installing static libraries. The original purpose for most static libraries has been made obsolete in a modern Linux system. In addition linking a static library into a program can be detrimental. If an update to the library is needed to remove a security problem, all programs that use the static library will need to be relinked to the new library. Since the use of static libraries is not always obvious, the relevant programs (and the procedures needed to do the linking) may not even be known.
          In the procedures in Chapter 6, we remove or disable
          installation of most static libraries. Usually this is done by
          passing a --disable-static option to
          configure. In other
          cases, alternate means are needed. In a few cases, especially glibc
          and gcc, the use of static libraries remains essential to the
          general package building process.
        
For a more complete discussion of libraries, see the discussion Libraries: Static or shared? in the BLFS book.