Building Temporarily Required Tools

Still working as lfs, proceed to compile Bash, Grep, and the native LFS-GCC, among others, with the cross toolchain that you created in LFS chapter 6. You can install the applications on the rudimentary LFS filesystem, but they cannot yet be used; you will still need the host system for certain tasks. At least the libraries installed in LFS are already used for linking. However, the applications will only really be used in the chroot environment in the next section.

For temporary tasks, you will need to compile a macro processor, a linker and an assembler, the native GCC compiler, a TUI (Text-based User Interface) library, as well as Bash, in the second run. In addition, a number of tools are created, including Awk, Chmod, Cp, Dd, Diff, File, Grep, Gzip, Make, Patch, Sed, Tar, and Xz.

Additional Temporary Tools

Up to this point, the user lfs has been the owner of the LFS file system; in chapter 7 of the LFS documentation, the owner changes to root. You then create the console and null devices on the disk, as the kernel expects these devices at boot time.

Resolving the circular dependencies means that, working as the root user for the first time, you can now switch to a chroot environment that almost completely locks out the build host's operating system for further tasks. The exception is the running kernel: For the chroot environment to work, communication with the kernel is configured via the Virtual Kernel File System (VFS).

VFSs are file systems (such as tmpfs/) that do not take up any disk space and are located entirely in main memory. Normally, the system mounts devices below /dev as virtual file systems, using Udev to create them when detected or on first accesses during the boot process. At the moment, Udev is still missing, so you will need to create the required devices manually and mount them via bind-mount. The pitfall is that, when you restart the LFS build host later, you need to re-run the mount commands for the virtual devices before continuing.

The first time you change to the chroot environment, an unusual Bash warning appears – /etc/passwd is missing. Now for the final directory structure, including some correctly set permissions plus some log files. The directory structure follows the Filesystem Hierarchy Standard (FHS) and creates, among other things, the /boot, /home, /mnt, /opt,and /srv directories, while leaving out things you don't need, such as /usr/local/games.

The standard users and groups are still missing. Because there are no standardized specifications, LFS follows Udev and other distributions. You then compile and install software to test other programs (using a temporarily created tester account). In addition, you are still missing some building blocks of the toolchain. Start by creating Libstdc++ (second run), a package for internationalization and locale support, a parser generator, and the Perl and Python programming languages. This is followed by tools for info pages and smaller utilities, such as Blkid, Dmesg, and others.

The toolchain you just completed now runs independently of the build host. At the end of the chapter, the LFS documentation deals with striping, backups, and restores, but I will not go into these topics in detail.

Installing Basic Software

The next chapter of the LFS documentation first gives an introduction to the topic of package management. It turns out, however, that the project does not use a package manager; the whole point of LFS is to learn to build things, so a package manager would simply not sit well with the orientation of LFS.

Some hard work follows. In chapter 8, for example, you use configure, make, and make install to add a whole bunch of applications to the disk, as well as some important libraries. In addition to Bash, the tools include text processors such as Awk, Grep, and Sed, as well as packers and archive programs such as Bzip, Gzip, Tar, and Xz. In addition, you will add GCC, the boot loader Grub, Man and Mandb, OpenSSL, Perl and Python, Vim, and Udev.

Compiling the GCC is by far the most time-consuming task in the entire project. This step takes almost half of the total compilation time by running the test suites. You will see masses of FAILED messages, but you don't need to worry about them as long as a grep on the log files generated by the test suite gives you the expected results. You can also safely ignore warnings about C syntax that appear during the compile process.

The unit tests carry out numerous variations on the make check or make test command, partly as the tester user (via su tester -c). If you skip these unit tests, you save a lot of time, but you also risk missing one or two problems in the build process.

After all this work, it's time to clean up. Remove libraries and tools that are no longer needed, as well as the temporary user, tester. If the LFS you created will not be used for programming and you do not need debugging functionality, you can save 2GB space by cleaning up the debugging symbols (which the code section takes into account).

Finally, leave the chroot environment and re-enter it immediately afterwards with bash path hashing [13] switched on.