diff --git a/Makefile b/Makefile index 5a24ccef3..44613e813 100644 --- a/Makefile +++ b/Makefile @@ -26,7 +26,7 @@ ifeq ($(REV), sysv) BASEDIR ?= ~/lfs-book PDF_OUTPUT ?= LFS-BOOK.pdf NOCHUNKS_OUTPUT ?= LFS-BOOK.html - DUMPDIR ?= ~/cross-lfs-commands + DUMPDIR ?= ~/lfs-commands else BASEDIR ?= ~/lfs-systemd PDF_OUTPUT ?= LFS-SYSD-BOOK.pdf @@ -150,7 +150,7 @@ validate: tmpdir version $(Q)xmllint --nonet \ --noent \ --postvalid \ - -o $(RENDERTMP)/lfs-full.xml \ + -o $(RENDERTMP)/lfs-full.xml \ $(RENDERTMP)/lfs-html2.xml $(Q)rm -f appendices/*.script @@ -161,9 +161,9 @@ profile-html: @echo "Generating profiled XML for XHTML..." $(Q)xsltproc --nonet \ --stringparam profile.condition html \ - --output $(RENDERTMP)/lfs-html.xml \ + --output $(RENDERTMP)/lfs-html.xml \ stylesheets/lfs-xsl/profile.xsl \ - $(RENDERTMP)/lfs-full.xml + $(RENDERTMP)/lfs-full.xml wget-list: $(BASEDIR)/wget-list $(BASEDIR)/wget-list-$(REV) $(BASEDIR)/wget-list: stylesheets/wget-list.xsl chapter03/chapter03.xml \ @@ -172,7 +172,7 @@ $(BASEDIR)/wget-list: stylesheets/wget-list.xsl chapter03/chapter03.xml \ $(Q)mkdir -p $(BASEDIR) $(Q)xsltproc --xinclude --nonet \ --output $(BASEDIR)/wget-list \ - stylesheets/wget-list.xsl \ + stylesheets/wget-list.xsl \ chapter03/chapter03.xml $(BASEDIR)/wget-list-$(REV): stylesheets/wget-list.xsl \ @@ -212,22 +212,17 @@ $(BASEDIR)/md5sums: stylesheets/wget-list.xsl chapter03/chapter03.xml \ version: $(Q)./git-version.sh $(REV) -#dump-commands: validate -# @echo "Dumping book commands..." -# $(Q)xsltproc --nonet \ -# --output $(RENDERTMP)/lfs-html.xml \ -# --stringparam profile.revision $(REV) \ -# stylesheets/lfs-xsl/profile.xsl \ -# $(RENDERTMP)/lfs-full.xml +dump-commands: validate + @echo "Dumping book commands..." -# $(Q)rm -rf $(DUMPDIR) + $(Q)rm -rf $(DUMPDIR) -# $(Q)xsltproc --output $(DUMPDIR)/ \ -# stylesheets/dump-commands.xsl \ -# $(RENDERTMP)/lfs-html.xml -# @echo "Dumping book commands complete in $(DUMPDIR)" + $(Q)xsltproc --output $(DUMPDIR)/ \ + stylesheets/dump-commands.xsl \ + $(RENDERTMP)/lfs-full.xml + @echo "Dumping book commands complete in $(DUMPDIR)" -all: book nochunks pdf # dump-commands +all: book nochunks pdf dump-commands .PHONY : all book dump-commands nochunks pdf profile-html tmpdir validate md5sums wget-list version diff --git a/appendices/dependencies.xml b/appendices/dependencies.xml index b59c93f93..69c676394 100644 --- a/appendices/dependencies.xml +++ b/appendices/dependencies.xml @@ -1186,7 +1186,7 @@ &external; - PCRE + PCRE2 and libsigsegv @@ -2356,7 +2356,7 @@ &runtime; - Glibc and Patch + Glibc diff --git a/bootscripts/ChangeLog b/bootscripts/ChangeLog index c1b590568..1fca16a65 100644 --- a/bootscripts/ChangeLog +++ b/bootscripts/ChangeLog @@ -1,3 +1,6 @@ +2022-09-30 Bruce Dubbs + * Mount /dev/shm as a tmpfs. + 2022-07-23 Thomas Trepl * Mark an raid array clean when root (/) has been remounted r/o when system goes down. Otherwise, array does remain diff --git a/bootscripts/lfs/init.d/mountvirtfs b/bootscripts/lfs/init.d/mountvirtfs index 639634377..21d98a05d 100644 --- a/bootscripts/lfs/init.d/mountvirtfs +++ b/bootscripts/lfs/init.d/mountvirtfs @@ -38,8 +38,8 @@ case "${1}" in mount /run || failed=1 fi - mkdir -p /run/lock /run/shm - chmod 1777 /run/shm /run/lock + mkdir -p /run/lock + chmod 1777 /run/lock log_info_msg "Mounting virtual file systems: ${INFO}/run" @@ -58,7 +58,9 @@ case "${1}" in mount -o mode=0755,nosuid /dev || failed=1 fi - ln -sfn /run/shm /dev/shm + mkdir -p /dev/shm + log_info_msg2 " ${INFO}/dev/shm" + mount -o nosuid,nodev /dev/shm || failed=1 (exit ${failed}) evaluate_retval diff --git a/bootscripts/lfs/init.d/swap b/bootscripts/lfs/init.d/swap index 9747024c5..14075ae19 100644 --- a/bootscripts/lfs/init.d/swap +++ b/bootscripts/lfs/init.d/swap @@ -20,8 +20,8 @@ # Should-Stop: $local_fs # Default-Start: S # Default-Stop: 0 6 -# Short-Description: Mounts and unmounts swap partitions. -# Description: Mounts and unmounts swap partitions defined in +# Short-Description: Activates and deactivates swap partitions. +# Description: Activates and deactivates swap partitions defined in # /etc/fstab. # X-LFS-Provided-By: LFS ### END INIT INFO diff --git a/chapter01/changelog.xml b/chapter01/changelog.xml index 384c78d21..fbf53f8f9 100644 --- a/chapter01/changelog.xml +++ b/chapter01/changelog.xml @@ -40,6 +40,69 @@ appropriate for the entry or if needed the entire day's listitem. --> + + 2022-10-01 + + + [bdubbs] - Update to iana-etc-20220922. Addresses + #5006. + + + [bdubbs] - Update to tzdata-2022d. Fixes + #5119. + + + [bdubbs] - Update to readline-8.2. Fixes + #5121. + + + [bdubbs] - Update to linux-5.19.12. Fixes + #5115. + + + [bdubbs] - Update to libffi-3.4.3. Fixes + #5116. + + + [bdubbs] - Update to libcap-2.66. Fixes + #5120. + + + [bdubbs] - Update to dbus-1.14.2. Fixes + #5123. + + + [bdubbs] - Update to bc-6.0.4. Fixes + #5114. + + + [bdubbs] - Update to bash-5.2. Fixes + #5122. + + + + + + 2022-09-22 + + + [bdubbs] - Update to expat-2.4.9 (Security Update). Fixes + #5117. + + + + + + 2022-09-20 + + + [bdubbs] - Adapt instructions depending on + host setup of /dev/shm when creating virtual filesystems + for chroot. + + + + 2022-09-15 diff --git a/chapter01/how.xml b/chapter01/how.xml index a690fb595..b7551b2e6 100644 --- a/chapter01/how.xml +++ b/chapter01/how.xml @@ -46,7 +46,7 @@ important issues you need be aware of before beginning to work your way through and beyond. - , explains the installation of + explains the installation of the initial tool chain, (binutils, gcc, and glibc) using cross compilation techniques to isolate the new tools from the host system. @@ -61,7 +61,7 @@ seem excessive. A full technical explanation as to why this is done is provided in . - In , The + In the full LFS system is built. Another advantage provided by the chroot environment is that it allows you to continue using the host system while LFS is being built. While waiting for package compilations to diff --git a/chapter01/whatsnew.xml b/chapter01/whatsnew.xml index d0bb33f14..ac7a4140c 100644 --- a/chapter01/whatsnew.xml +++ b/chapter01/whatsnew.xml @@ -11,6 +11,14 @@ What's new since the last release + In 11.3 release, --enable-default-pie + and --enable-default-ssp are enabled for GCC. + They can mitigate some type of malicious attacks but they cannot provide + a full protection. In case if you are reading a programming textbook, + you may need to disable PIE and SSP with GCC options + -fno-pie -no-pie -fno-stack-protection + because some textbooks assume they were disabled by default. + Below is a list of package updates made since the previous release of the book. @@ -38,9 +46,9 @@ - + Bc &bc-version; @@ -62,9 +70,9 @@ - + @@ -74,9 +82,9 @@ - + @@ -122,9 +130,9 @@ - + @@ -149,15 +157,15 @@ - + - + @@ -218,9 +226,9 @@ Python-&python-version; - + @@ -245,9 +253,9 @@ - + diff --git a/chapter02/aboutlfs.xml b/chapter02/aboutlfs.xml index 41b50a2a0..85ffd5b57 100644 --- a/chapter02/aboutlfs.xml +++ b/chapter02/aboutlfs.xml @@ -14,8 +14,8 @@ be used several times. You should ensure that this variable is always defined throughout the LFS build process. It should be set to the name of the directory where you will be building your LFS system - we will use - /mnt/lfs as an example, but the - directory choice is up to you. If you are building LFS on a separate + /mnt/lfs as an example, but you may + choose any directory name you want. If you are building LFS on a separate partition, this directory will be the mount point for the partition. Choose a directory location and set the variable with the following command: @@ -25,7 +25,7 @@ Having this variable set is beneficial in that commands such as mkdir -v $LFS/tools can be typed literally. The shell will automatically replace $LFS with - /mnt/lfs (or whatever the variable was set to) when it + /mnt/lfs (or whatever value the variable was set to) when it processes the command line. @@ -49,7 +49,7 @@ personal home directory and in /root/.bash_profile and enter the export command above. In addition, the shell specified in the /etc/passwd file for all users that need the - LFS variable needs to be bash to ensure that the + LFS variable must be bash to ensure that the /root/.bash_profile file is incorporated as a part of the login process. @@ -59,9 +59,9 @@ a virtual terminal is started. In this case, add the export command to the .bashrc file for the user and root. In addition, - some distributions have instructions to not run the .bashrc - instructions in a non-interactive bash invocation. Be sure to add the - export command before the test for non-interactive use. + some distributions use an "if" test, and do not run the remaining .bashrc + instructions for a non-interactive bash invocation. Be sure to place the + export command ahead of the test for non-interactive use. diff --git a/chapter02/creatingfilesystem.xml b/chapter02/creatingfilesystem.xml index 1996f1cee..5eedf456e 100644 --- a/chapter02/creatingfilesystem.xml +++ b/chapter02/creatingfilesystem.xml @@ -10,10 +10,19 @@ Creating a File System on the Partition - Now that a blank partition has been set up, the file system can be - created. LFS can use any file system recognized by the Linux kernel, but the - most common types are ext3 and ext4. The choice of file system can be - complex and depends on the characteristics of the files and the size of + A partition is just a range of sectors on a disk drive, delimited by + boundaries set in a partition table. Before the operating system can use + a partition to store any files, the partition must be formatted to contain a file + system, typically consisting of a label, directory blocks, data blocks, and + an indexing scheme to locate a particular file on demand. The file system + also helps the OS keep track of free space on the partition, reserve the + needed sectors when a new file is created or an existing file is extended, + and recycle the free data segments created when files are deleted. It may + also provide support for data redundancy, and for error recovery. + + LFS can use any file system recognized by the Linux kernel, but the + most common types are ext3 and ext4. The choice of the right file system can be + complex; it depends on the characteristics of the files and the size of the partition. For example: @@ -33,22 +42,22 @@ ext4 - is the latest version of the ext file system family of - partition types. It provides several new capabilities including - nano-second timestamps, creation and use of very large files (16 TB), and - speed improvements. + is the latest version of the ext family of + file systems. It provides several new capabilities including + nano-second timestamps, creation and use of very large files + (up to 16 TB), and speed improvements. Other file systems, including FAT32, NTFS, ReiserFS, JFS, and XFS are - useful for specialized purposes. More information about these file systems - can be found at . - LFS assumes that the root file system (/) is of type ext4. To create + LFS assumes that the root file system (/) is of type ext4. To create an ext4 file system on the LFS - partition, run the following: + partition, issue the following command: mkfs -v -t ext4 /dev/<xxx> diff --git a/chapter02/creatingpartition.xml b/chapter02/creatingpartition.xml index c532bdb15..d5429ad7c 100644 --- a/chapter02/creatingpartition.xml +++ b/chapter02/creatingpartition.xml @@ -94,10 +94,10 @@ Swapping is never good. For mechanical hard drives you can generally tell if a system is swapping by just listening to disk activity and - observing how the system reacts to commands. For an SSD drive you will not - be able to hear swapping but you can tell how much swap space is being used - by the top or free programs. Use of - an SSD drive for a swap partition should be avoided if possible. The first + observing how the system reacts to commands. With an SSD you will not + be able to hear swapping, but you can tell how much swap space is being used + by running the top or free programs. Use of + an SSD for a swap partition should be avoided if possible. The first reaction to swapping should be to check for an unreasonable command such as trying to edit a five gigabyte file. If swapping becomes a normal occurrence, the best solution is to purchase more RAM for your @@ -112,12 +112,12 @@ must be available for GRUB to use during installation of the boot loader. This partition will normally be labeled 'BIOS Boot' if using fdisk or have a code of EF02 if - using gdisk. + using the gdisk command. The Grub Bios partition must be on the drive that the BIOS - uses to boot the system. This is not necessarily the same drive where the - LFS root partition is located. Disks on a system may use different - partition table types. The requirement for this partition depends + uses to boot the system. This is not necessarily the drive that holds + the LFS root partition. The disks on a system may use different + partition table types. The necessity of the Grub Bios partition depends only on the partition table type of the boot disk. @@ -133,7 +133,7 @@ /boot – Highly recommended. Use this partition to store kernels and other booting information. To minimize potential boot problems with larger disks, make this the first physical partition on - your first disk drive. A partition size of 200 megabytes is quite + your first disk drive. A partition size of 200 megabytes is adequate. /boot/efi – The EFI System Partition, which is @@ -150,41 +150,50 @@ /bin, /lib, and /sbin are symlinks to their - counterpart in /usr. - So /usr contains all binaries + counterparts in /usr. + So /usr contains all the binaries needed for the system to run. For LFS a separate partition for /usr is normally not needed. - If you need it anyway, you should make a partition large enough to - fit all programs and libraries in the system. The root partition can be + If you create it anyway, you should make a partition large enough to + fit all the programs and libraries in the system. The root partition can be very small (maybe just one gigabyte) in this configuration, so it's suitable for a thin client or diskless workstation (where /usr is mounted from a remote - server). However you should take care that an initramfs (not covered by - LFS) will be needed to boot a system with separate + server). However, you should be aware that an initramfs (not covered by + LFS) will be needed to boot a system with a separate /usr partition. /opt – This directory is most useful for - BLFS where multiple installations of large packages like Gnome or KDE can + BLFS, where multiple large packages like KDE or Texlive can be installed without embedding the files in the /usr hierarchy. If used, 5 to 10 gigabytes is generally adequate. - /tmp – A separate /tmp directory is rare, but - useful if configuring a thin client. This partition, if used, will - usually not need to exceed a couple of gigabytes. + /tmp – A separate /tmp directory + is rare, but useful if configuring a thin client. This partition, if + used, will usually not need to exceed a couple of + gigabytes. If you have enough RAM, you can mount a + tmpfs on /tmp to make + access to temporary files faster. + + /tmp – By default, systemd + mounts a tmpfs here. + If you want to override that behavior, follow + when configuring the LFS + system. /usr/src – This partition is very useful for providing a location to store BLFS source files and - share them across LFS builds. It can also be used as a location - for building BLFS packages. A reasonably large partition of 30-50 - gigabytes allows plenty of room. + share them across LFS builds. It can also be used as a location + for building BLFS packages. A reasonably large partition of 30-50 + gigabytes provides plenty of room. - Any separate partition that you want automatically mounted upon boot - needs to be specified in the /etc/fstab. Details - about how to specify partitions will be discussed in . + Any separate partition that you want automatically mounted when the + system starts must be specified in the /etc/fstab file. + Details about how to specify partitions will be discussed in . diff --git a/chapter02/hostreqs.xml b/chapter02/hostreqs.xml index cf49a7c96..4544d95c2 100644 --- a/chapter02/hostreqs.xml +++ b/chapter02/hostreqs.xml @@ -36,7 +36,7 @@ Bison-2.7 (/usr/bin/yacc - should be a link to bison or small script that executes bison) + should be a link to bison or a small script that executes bison) diff --git a/chapter02/mounting.xml b/chapter02/mounting.xml index a4408c94f..1c2e7205e 100644 --- a/chapter02/mounting.xml +++ b/chapter02/mounting.xml @@ -10,24 +10,28 @@ Mounting the New Partition - Now that a file system has been created, the partition needs to - be made accessible. In order to do this, the partition needs to be - mounted at a chosen mount point. For the purposes of this book, it is - assumed that the file system is mounted under the directory specified by the - LFS environment variable as described in the previous section. + Now that a file system has been created, the partition must + be mounted so the host system can access it. This book assumes that + the file system is mounted at the directory specified by the + LFS environment variable described in the previous section. + + Strictly speaking, one cannot "mount a partition". One mounts the file + system embedded in that partition. But since a single partition can't contain + more than one file system, people often speak of the partition and the + associated file system as if they were one and the same. - Create the mount point and mount the LFS file system by running: + Create the mount point and mount the LFS file system with these commands: mkdir -pv $LFS mount -v -t ext4 /dev/<xxx> $LFS - Replace <xxx> with the designation of the LFS + Replace <xxx> with the name of the LFS partition. - If using multiple partitions for LFS (e.g., one for / and another for /home), mount them using: + If you are using multiple partitions for LFS (e.g., one for + / and another for /home), mount them like this: mkdir -pv $LFS mount -v -t ext4 /dev/<xxx> $LFS @@ -43,13 +47,14 @@ mount -v -t ext4 /dev/<yyy> $LFS/homenodev options). Run the mount command without any parameters to see what options are set for the mounted LFS partition. If and/or are set, - the partition will need to be remounted. + the partition must be remounted. - The above instructions assume that you will not be restarting + The above instructions assume that you will not restart your computer throughout the LFS process. If you shut down your system, you will either need to remount the LFS partition each time you restart - the build process or modify your host system's /etc/fstab file to automatically - remount it upon boot. For example: + the build process, or modify the host system's &fstab; file to automatically + remount it when you reboot. For example, you might add this line to your + &fstab; file: /dev/<xxx> /mnt/lfs ext4 defaults 1 1 @@ -67,7 +72,7 @@ mount -v -t ext4 /dev/<yyy> $LFS/homeReplace <zzz> with the name of the swap partition. - Now that there is an established place to work, it is time to + Now that the new LFS partition is open for business, it's time to download the packages. diff --git a/chapter02/stages.xml b/chapter02/stages.xml index 7c151975f..036cd34cc 100644 --- a/chapter02/stages.xml +++ b/chapter02/stages.xml @@ -34,7 +34,7 @@ - Chapter 5–6 + Chapters 5–6 @@ -44,8 +44,8 @@ These two chapters must be done as user lfs. - A su - lfs needs to be done before any task in these - chapters. Failing to do that, you are at risk of installing packages to the + A su - lfs command must be issued before any task in these + chapters. If you don't do that, you are at risk of installing packages to the host, and potentially rendering it unusable. @@ -54,13 +54,13 @@ are critical. If there is any doubt about installing a package, ensure any previously expanded tarballs are removed, then re-extract the package files, and complete all - instructions in that section. + the instructions in that section. - Chapter 7–10 + Chapters 7–10 @@ -69,7 +69,7 @@ A few operations, from Changing Ownership to - Entering the Chroot Environment must be done as the + Entering the Chroot Environment, must be done as the root user, with the LFS environment variable set for the &root; user. @@ -77,7 +77,7 @@ When entering chroot, the LFS environment variable must be set for root. The LFS - variable is not used afterwards. + variable is not used after entering the chroot environment. diff --git a/chapter03/introduction.xml b/chapter03/introduction.xml index 1b658e89d..1a69187a2 100644 --- a/chapter03/introduction.xml +++ b/chapter03/introduction.xml @@ -13,17 +13,17 @@ This chapter includes a list of packages that need to be downloaded in order to build a basic Linux system. The listed version numbers correspond to versions of the software that are known to work, and this book is based on - their use. We highly recommend against using different versions because the build + their use. We highly recommend against using different versions, because the build commands for one version may not work with a different version, unless the - different version is specified by a LFS errata or security advisory. + different version is specified by an LFS erratum or security advisory. The newest package versions may also have problems that require work-arounds. These work-arounds will be developed and stabilized in the development version of the book. For some packages, the release tarball and the (Git or SVN) - repository snapshot tarball for this release may be published with - similar file name. A release tarball contains generated files (for - example, configure script generated by + repository snapshot tarball for that release may be published with + similar file names. A release tarball contains generated files (for + example, a configure script generated by autoconf), in addition to the contents of the corresponding repository snapshot. The book uses release tarballs whenever possible. Using a repository snapshot instead of a release @@ -69,7 +69,7 @@ For stable versions of the book, a tarball of all the needed files - can be downloaded from one of the LFS files mirrors listed at + can be downloaded from one of the mirror sites listed at . diff --git a/chapter03/packages.xml b/chapter03/packages.xml index ce331d39a..38c08e0f9 100644 --- a/chapter03/packages.xml +++ b/chapter03/packages.xml @@ -15,14 +15,14 @@ before downloading packages to figure out if a newer version of any package should be used to avoid security vulnerabilities. - The upstreams may remove old releases, especially when these + The upstream sources may remove old releases, especially when those releases contain a security vulnerability. If one URL below is not reachable, you should read the security advisories first to figure out if a newer version (with the vulnerability fixed) should be used. If not, try to download the removed package from a mirror. Although it's possible to download an old release from a mirror even if this release - has been removed because of a vulnerability, it's not recommended to - use a release known to be vulnerable for building your system. + has been removed because of a vulnerability, it's not a good idea to + use a release known to be vulnerable when building your system. Download or otherwise obtain the following packages: @@ -462,7 +462,7 @@ MD5 sum: &linux-md5; - The Linux kernel is updated relatively often, many times due to + The Linux kernel is updated quite frequently, many times due to discoveries of security vulnerabilities. The latest available stable kernel version may be diff --git a/chapter04/aboutsbus.xml b/chapter04/aboutsbus.xml index 1928423ea..82934d851 100644 --- a/chapter04/aboutsbus.xml +++ b/chapter04/aboutsbus.xml @@ -13,25 +13,25 @@ Many people would like to know beforehand approximately how long it takes to compile and install each package. Because Linux From Scratch can be built on many different systems, it is impossible to - provide accurate time estimates. The biggest package (Glibc) will + provide absolute time estimates. The biggest package (Glibc) will take approximately 20 minutes on the fastest systems, but could take up to three days on slower systems! Instead of providing actual times, the Standard Build Unit (SBU) measure will be used instead. The SBU measure works as follows. The first package to be compiled - from this book is binutils in . The - time it takes to compile this package is what will be referred to as the - Standard Build Unit or SBU. All other compile times will be expressed relative - to this time. + is binutils in . The + time it takes to compile this package is what we will refer to as the + Standard Build Unit or SBU. All other compile times will be expressed in + terms of this unit of time. For example, consider a package whose compilation time is 4.5 - SBUs. This means that if a system took 10 minutes to compile and + SBUs. This means that if your system took 10 minutes to compile and install the first pass of binutils, it will take - approximately 45 minutes to build this example package. - Fortunately, most build times are shorter than the one for binutils. + approximately 45 minutes to build the example package. + Fortunately, most build times are shorter than one SBU. - In general, SBUs are not entirely accurate because they depend on many + SBUs are not entirely accurate because they depend on many factors, including the host system's version of GCC. They are provided here to give an estimate of how long it might take to install a package, but the numbers can vary by as much as dozens of minutes in some cases. @@ -45,15 +45,15 @@ export MAKEFLAGS='-j4' - or just building with: + or by building with: make -j4 When multiple processors are used in this way, the SBU units in the book will vary even more than they normally would. In some cases, the make step will simply fail. Analyzing the output of the build process will also - be more difficult because the lines of different processes will be - interleaved. If you run into a problem with a build step, revert back to a + be more difficult because the lines from different processes will be + interleaved. If you run into a problem with a build step, revert to a single processor build to properly analyze the error messages. diff --git a/chapter04/abouttestsuites.xml b/chapter04/abouttestsuites.xml index 9206f33be..459472be0 100644 --- a/chapter04/abouttestsuites.xml +++ b/chapter04/abouttestsuites.xml @@ -27,21 +27,21 @@ Running the test suites in and - is impossible, since the programs are compiled with a cross-compiler, - so are not supposed to be able to run on the build host. + is pointless; since the test programs are compiled with a cross-compiler, + they probably can't run on the build host. A common issue with running the test suites for binutils and GCC - is running out of pseudo terminals (PTYs). This can result in a high + is running out of pseudo terminals (PTYs). This can result in a large number of failing tests. This may happen for several reasons, but the most likely cause is that the host system does not have the devpts file system set up correctly. This issue is discussed in greater detail at . - Sometimes package test suites will fail, but for reasons which the + Sometimes package test suites will fail for reasons which the developers are aware of and have deemed non-critical. Consult the logs located at to verify whether or not these failures are - expected. This site is valid for all tests throughout this book. + expected. This site is valid for all test suites throughout this book. diff --git a/chapter04/addinguser.xml b/chapter04/addinguser.xml index 00f9c57ae..938c01ee7 100644 --- a/chapter04/addinguser.xml +++ b/chapter04/addinguser.xml @@ -14,9 +14,9 @@ making a single mistake can damage or destroy a system. Therefore, the packages in the next two chapters are built as an unprivileged user. You could use your own user name, but to make it easier to set up a clean - working environment, create a new user called lfs as a member of a new group (also named - lfs) and use this user during + lfs) and run commands as &lfs-user; during the installation process. As root, issue the following commands to add the new user: @@ -24,7 +24,7 @@ useradd -s /bin/bash -g lfs -m -k /dev/null lfs - The meaning of the command line options: + This is what the command line options mean: -s /bin/bash @@ -54,7 +54,7 @@ useradd -s /bin/bash -g lfs -m -k /dev/null lfs -k /dev/null This parameter prevents possible copying of files from a skeleton - directory (default is /etc/skel) + directory (the default is /etc/skel) by changing the input location to the special null device. @@ -68,17 +68,17 @@ useradd -s /bin/bash -g lfs -m -k /dev/null lfs - To log in as lfs (as opposed - to switching to user lfs when logged - in as root, which does not require - the lfs user to have a password), - give lfs a password: + If you want to log in as &lfs-user; or switch to &lfs-user; from a + non-&root; user (as opposed to switching to user &lfs-user; + when logged in as &root;, which does not require the &lfs-user; user to + have a password), you need to set a password of &lfs-user;. Issue the + following command as the &root; user to set the password: passwd lfs Grant lfs full access to - all directories under $LFS by making - lfs the directory owner: + all the directories under $LFS by making + lfs the owner: chown -v lfs $LFS/{usr{,/*},lib,var,etc,bin,sbin,tools} case $(uname -m) in @@ -88,20 +88,20 @@ esac chown -v lfs $LFS/libx32 chown -v lfs $LFS/{lib32,libx32} - In some host systems, the following command does not complete - properly and suspends the login to the &lfs-user; user to the background. +In some host systems, the following su command does not complete + properly and suspends the login for the &lfs-user; user to the background. If the prompt "lfs:~$" does not appear immediately, entering the fg command will fix the issue. - Next, login as user lfs. - This can be done via a virtual console, through a display manager, or with - the following substitute/switch user command: + Next, start a shell running as user &lfs-user;. This can be done by + logging in as &lfs-user; on a virtual console, or with the following + substitute/switch user command: su - lfs The - instructs su to start a login shell as opposed to a non-login shell. - The difference between these two types of shells can be found in detail in + The difference between these two types of shells is described in detail in bash(1) and info bash. diff --git a/chapter04/creatingminlayout.xml b/chapter04/creatingminlayout.xml index 1cc01af92..41ec2b7f0 100644 --- a/chapter04/creatingminlayout.xml +++ b/chapter04/creatingminlayout.xml @@ -10,14 +10,15 @@ Creating a limited directory layout in LFS filesystem - The first task performed in the LFS partition is to create a limited - directory hierarchy so that programs compiled in In this section, we begin populating the LFS filesystem with the + pieces that will constitute the final Linux system. The first step is to + create a limited directory hierarchy, so that the programs compiled in (as well as glibc and libstdc++ in ) may be installed in their final - location. This is needed so that those temporary programs be overwritten - when rebuilding them in . + linkend="chapter-cross-tools"/>) can be installed in their final + location. We do this so those temporary programs will be overwritten when + the final versions are built in . - Create the required directory layout by running the following as + Create the required directory layout by issuing the following commands as root: mkdir -pv $LFS/{etc,var} $LFS/usr/{bin,lib,sbin} @@ -38,10 +39,10 @@ ln -sv usr/lib32 $LFS/lib32 ln -sv usr/libx32 $LFS/libx32 Programs in will be compiled - with a cross-compiler (more details in section ). In order to separate this - cross-compiler from the other programs, it will be installed in a special - directory. Create this directory with: + with a cross-compiler (more details can be found in section ). This cross-compiler will be installed + in a special directory, to separate it from the other programs. Still acting as + &root;, create that directory with this command: mkdir -pv $LFS/tools diff --git a/chapter04/introduction.xml b/chapter04/introduction.xml index c54c67f8c..e2ef6f0ba 100644 --- a/chapter04/introduction.xml +++ b/chapter04/introduction.xml @@ -12,11 +12,11 @@ In this chapter, we will perform a few additional tasks to prepare for building the temporary system. We will create a set of directories in - $LFS for the installation of the - temporary tools, add an unprivileged user to reduce risk, + $LFS (in which we will install the + temporary tools), add an unprivileged user, and create an appropriate build environment for that user. We will also - explain the unit of time we use to measure how long LFS packages take to - build, or SBUs, and give some information about package + explain the units of time (SBUs) we use to measure how + long it takes to build LFS packages, and provide some information about package test suites. diff --git a/chapter04/settingenviron.xml b/chapter04/settingenviron.xml index 98de2c66a..dcd183c56 100644 --- a/chapter04/settingenviron.xml +++ b/chapter04/settingenviron.xml @@ -19,8 +19,10 @@ exec env -i HOME=$HOME TERM=$TERM PS1='\u:\w\$ ' /bin/bash EOF - When logged on as user lfs, - the initial shell is usually a login shell which reads + When logged on as user lfs + or switched to the &lfs-user; user using a su command + with - option, + the initial shell is a login shell which reads the /etc/profile of the host (probably containing some settings and environment variables) and then .bash_profile. The exec env -i.../bin/bash command in the @@ -32,7 +34,7 @@ EOF ensuring a clean environment. The new instance of the shell is a non-login - shell, which does not read, and execute, the contents of /etc/profile or + shell, which does not read, and execute, the contents of the /etc/profile or .bash_profile files, but rather reads, and executes, the .bashrc file instead. Create the .bashrc file now: @@ -73,10 +75,10 @@ EOF The set +h command turns off bash's hash function. Hashing is ordinarily a useful feature—bash uses a hash table to remember the - full path of executable files to avoid searching the PATH + full path to executable files to avoid searching the PATH time and again to find the same executable. However, the new tools should - be used as soon as they are installed. By switching off the hash function, - the shell will always search the PATH when a program is to + be used as soon as they are installed. Switching off the hash function forces + the shell to search the PATH whenever a program is to be run. As such, the shell will find the newly compiled tools in $LFS/tools/bin as soon as they are available without remembering a previous version of the same program @@ -129,10 +131,10 @@ EOF PATH=/usr/bin - Many modern linux distributions have merged Many modern Linux distributions have merged /bin and /usr/bin. When this is the case, the standard - PATH variable needs just to be set to PATH variable should be set to /usr/bin/ for the environment. When this is not the case, the following line adds /bin @@ -155,7 +157,7 @@ EOF standard PATH, the cross-compiler installed at the beginning of is picked up by the shell immediately after its installation. This, combined with turning off hashing, - limits the risk that the compiler from the host be used instead of the + limits the risk that the compiler from the host is used instead of the cross-compiler. @@ -209,7 +211,8 @@ EOF Finally, to have the environment fully prepared for building the - temporary tools, source the just-created user profile: + temporary tools, force the bash shell to read + the new user profile: source ~/.bash_profile diff --git a/chapter07/cleanup.xml b/chapter07/cleanup.xml index d3104d1a6..928743e7a 100644 --- a/chapter07/cleanup.xml +++ b/chapter07/cleanup.xml @@ -18,10 +18,10 @@ rm -rf /usr/share/{info,man,doc}/* - Second, the libtool .la files are only useful when linking with static - libraries. They are unneeded and potentially harmful when using dynamic - shared libraries, especially when using non-autotools build systems. - While still in chroot, remove those files now: + Second, on a modern Linux system, the libtool .la files are only + useful for libltdl. No libraries in LFS are expected to be loaded by + libltdl, and it's known that some .la files can cause BLFS packages + fail to build. Remove those files now: find /usr/{lib,libexec} -name \*.la -delete find /usr/lib32 -name \*.la -delete @@ -98,7 +98,8 @@ find /usr/lib{,x}32 -name \*.la -delete Before making a backup, unmount the virtual file systems: -umount $LFS/dev/pts +mountpoint -q $LFS/dev/shm && umount $LFS/dev/shm +umount $LFS/dev/pts umount $LFS/{sys,proc,run,dev} diff --git a/chapter07/creatingdirs.xml b/chapter07/creatingdirs.xml index 4ac1d62bb..c242f0464 100644 --- a/chapter07/creatingdirs.xml +++ b/chapter07/creatingdirs.xml @@ -10,10 +10,10 @@ Creating Directories - It is time to create the full structure in the LFS file system. + It is time to create the full directory structure in the LFS file system. - Some of the directories mentioned in this section may be - already created earlier with explicit instructions or when installing some + Some of the directories mentioned in this section may have + already been created earlier with explicit instructions, or when installing some packages. They are repeated below for completeness. Create some root-level directories that are not in the limited set @@ -45,14 +45,14 @@ install -dv -m 1777 /tmp /var/tmp support has already been created while previous installation steps. Directories are, by default, created with permission mode 755, but - this is not desirable for all directories. In the commands above, two + this is not desirable everywhere. In the commands above, two changes are made—one to the home directory of user root, and another to the directories for temporary files. The first mode change ensures that not just anybody can enter - the /root directory—the - same as a normal user would do with his or her home directory. The + the /root directory—just + like a normal user would do with his or her own home directory. The second mode change makes sure that any user can write to the /tmp and /var/tmp directories, but cannot remove @@ -62,14 +62,14 @@ install -dv -m 1777 /tmp /var/tmp FHS Compliance Note - The directory tree is based on the Filesystem Hierarchy Standard + This directory tree is based on the Filesystem Hierarchy Standard (FHS) (available at ). The FHS also specifies - the optional existence of some directories such as /usr/local/games and /usr/share/games. We create only the - directories that are needed. However, feel free to create these - directories. + class="directory">/usr/share/games. In LFS, we create only the + directories that are really necessary. However, feel free to create more + directories, if you wish. diff --git a/chapter07/introduction.xml b/chapter07/introduction.xml index 6605ddea4..d00f3fe2a 100644 --- a/chapter07/introduction.xml +++ b/chapter07/introduction.xml @@ -11,22 +11,22 @@ Introduction This chapter shows how to build the last missing bits of the temporary - system: the tools needed by the build machinery of various packages. Now + system: the tools needed to build the various packages. Now that all circular dependencies have been resolved, a chroot environment, completely isolated from the host operating system (except for the running kernel), can be used for the build. For proper operation of the isolated environment, some communication - with the running kernel must be established. This is done through the - so-called Virtual Kernel File Systems, which must be - mounted when entering the chroot environment. You may want to check - that they are mounted by issuing findmnt. + with the running kernel must be established. This is done via the + so-called Virtual Kernel File Systems, which will be + mounted before entering the chroot environment. You may want to verify + that they are mounted by issuing the findmnt command. Until , the commands must be run as root, with the LFS variable set. After entering chroot, all commands are run as &root;, fortunately without access to the OS of the computer you built LFS on. Be careful anyway, as it is easy to destroy the whole - LFS system with badly formed commands. + LFS system with bad commands. diff --git a/chapter07/kernfs.xml b/chapter07/kernfs.xml index 64db54c24..3e96bee5e 100644 --- a/chapter07/kernfs.xml +++ b/chapter07/kernfs.xml @@ -14,12 +14,14 @@ /dev/* - Various file systems exported by the kernel are used to communicate to - and from the kernel itself. These file systems are virtual in that no disk + Applications running in user space utilize various file + systems exported by the kernel to communicate + with the kernel itself. These file systems are virtual: no disk space is used for them. The content of the file systems resides in - memory. + memory. These file systems must be mounted in the $LFS directory tree + so the applications can find them in the chroot environment. - Begin by creating directories onto which the file systems will be + Begin by creating directories on which the file systems will be mounted: mkdir -pv $LFS/{dev,proc,sys,run} @@ -27,20 +29,31 @@ Mounting and Populating /dev - During a normal boot, the kernel automatically mounts the - devtmpfs filesystem on the - /dev directory, and allow the - devices to be created dynamically on that virtual filesystem as they - are detected or accessed. Device creation is generally done during the - boot process by the kernel and Udev. - Since this new system does not yet have Udev and - has not yet been booted, it is necessary to mount and populate - /dev manually. This is - accomplished by bind mounting the host system's + During a normal boot of the LFS system, the kernel automatically + mounts the devtmpfs + filesystem on the + /dev directory; the kernel + creates device nodes on that virtual filesystem during the boot process + or when a device is first detected or accessed. The udev daemon may + change the owner or permission of the device nodes created by the + kernel, or create new device nodes or symlinks to ease the work of + distro maintainers or system administrators. (See + for details.) + If the host kernel supports &devtmpfs;, we can simply mount a + &devtmpfs; at $LFS/dev and rely + on the kernel to populate it (the LFS building process does not need + the additional work onto &devtmpfs; by udev daemon). + + But, some host kernels may lack &devtmpfs; support and these + host distros maintain the content of + /dev with different methods. + So the only host-agnostic way for populating + $LFS/dev is + bind mounting the host system's /dev directory. A bind mount is a special type of mount that allows you to create a mirror of a - directory or mount point to some other location. Use the following - command to achieve this: + directory or mount point at some other location. Use the following + command to do this: mount -v --bind /dev $LFS/dev @@ -89,8 +102,15 @@ mount -vt tmpfs tmpfs $LFS/run The /run tmpfs was mounted above so in this case only a directory needs to be created. + In other host systems /dev/shm is a mount point + for a tmpfs. In that case the mount of /dev above will only create + /dev/shm as a directory in the chroot environment. In this situation + we must explicitly mount a tmpfs: + if [ -h $LFS/dev/shm ]; then mkdir -pv $LFS/$(readlink $LFS/dev/shm) +else + mount -t tmpfs -o nosuid,nodev tmpfs $LFS/dev/shm fi diff --git a/chapter08/autoconf.xml b/chapter08/autoconf.xml index d7563963b..7925e44ea 100644 --- a/chapter08/autoconf.xml +++ b/chapter08/autoconf.xml @@ -40,12 +40,13 @@ Installation of Autoconf - + First, fix several problems with the tests caused by bash-5.2 and later: + + sed -e 's/SECONDS|/&SHLVL|/' \ + -e '/BASH_ARGV=/a\ /^SHLVL=/ d' \ + -i.orig tests/local.at + Prepare Autoconf for compilation: ./configure --prefix=/usr diff --git a/chapter08/binutils.xml b/chapter08/binutils.xml index 84522a0e9..fe360c897 100644 --- a/chapter08/binutils.xml +++ b/chapter08/binutils.xml @@ -178,16 +178,16 @@ cd build make -k check -Twelve tests fail in the gold testsuite when the + Twelve tests fail in the gold testsuite when the and - options are passed to GCC. There - is also a known failure in the as tests. - + options are passed to GCC. + + The test named ar with versioned solib is also + known to fail. + Install the package: make tooldir=/usr install diff --git a/chapter08/cleanup.xml b/chapter08/cleanup.xml index 20c4c9e23..c5db3440d 100644 --- a/chapter08/cleanup.xml +++ b/chapter08/cleanup.xml @@ -16,10 +16,10 @@ There are also several files installed in the /usr/lib and /usr/libexec directories with a file name extension of .la. These are "libtool archive" - files. As already said, they are only useful when linking with static - libraries. They are unneeded, and potentially harmful, when using dynamic - shared libraries, specially when using also non-autotools build systems. - To remove them, run: + files. As already said, on a modern Linux system the libtool .la files are + only useful for libltdl. No libraries in LFS are expected to be loaded + by libltdl, and it's known that some .la files can cause BLFS packages + fail to build. Remove those files now: find /usr/lib /usr/libexec -name \*.la -delete find /usr/lib32 -name \*.la -delete diff --git a/chapter08/gawk.xml b/chapter08/gawk.xml index 244d7004f..9979e32de 100644 --- a/chapter08/gawk.xml +++ b/chapter08/gawk.xml @@ -46,7 +46,7 @@ Now fix a programming error identified upstream: -sed -i -i '241i UPREF(m);' interpret.h +sed -i '241i UPREF(m);' interpret.h Prepare Gawk for compilation: diff --git a/chapter08/gcc.xml b/chapter08/gcc.xml index baa262c0c..e9805ebd0 100644 --- a/chapter08/gcc.xml +++ b/chapter08/gcc.xml @@ -132,7 +132,7 @@ cd build PIE (position-independent executable) is a technique to produce binary programs that can be loaded anywhere in memory. Without PIE, the security feature named ASLR (Address Space Layout Randomization) - can be applied for the shared libraries, but not the exectutable + can be applied for the shared libraries, but not the executable itself. Enabling PIE allows ASLR for the executables in addition to the shared libraries, and mitigates some attacks based on fixed addresses of sensitive code or data in the executables. diff --git a/chapter08/libelf.xml b/chapter08/libelf.xml index 9fc883b99..4d3332fd1 100644 --- a/chapter08/libelf.xml +++ b/chapter08/libelf.xml @@ -58,7 +58,8 @@ make check - + One test named run-low_high_pc.sh is known to + fail on 32-bit x86 system. Install only Libelf: diff --git a/chapter08/pkgmgt.xml b/chapter08/pkgmgt.xml index b925a976f..5d9477e80 100644 --- a/chapter08/pkgmgt.xml +++ b/chapter08/pkgmgt.xml @@ -11,13 +11,13 @@ Package Management Package Management is an often requested addition to the LFS Book. A - Package Manager allows tracking the installation of files making it easy to + Package Manager tracks the installation of files, making it easier to remove and upgrade packages. As well as the binary and library files, a package manager will handle the installation of configuration files. Before you begin to wonder, NO—this section will not talk about nor recommend any particular package manager. What it provides is a roundup of the more popular techniques and how they work. The perfect package manager for you may - be among these techniques or may be a combination of two or more of these + be among these techniques, or it may be a combination of two or more of these techniques. This section briefly mentions issues that may arise when upgrading packages. @@ -32,14 +32,14 @@ There are multiple solutions for package management, each having - its strengths and drawbacks. Including one that satisfies all audiences + its strengths and drawbacks. Finding one solution that satisfies all audiences is difficult. There are some hints written on the topic of package management. Visit the Hints Project and see if one of them - fits your need. + fits your needs. Upgrade Issues @@ -51,18 +51,18 @@ - If Linux kernel needs to be upgraded (for example, from - 5.10.17 to 5.10.18 or 5.11.1), nothing else need to be rebuilt. - The system will keep working fine thanks to the well-defined border - between kernel and userspace. Specifically, Linux API headers - need not to be (and should not be, see the next item) upgraded - alongside the kernel. You'll need to reboot your system to use the + If the Linux kernel needs to be upgraded (for example, from + 5.10.17 to 5.10.18 or 5.11.1), nothing else needs to be rebuilt. + The system will keep working fine thanks to the well-defined interface + between the kernel and user space. Specifically, Linux API headers + need not be (and should not be, see the next item) upgraded + along with the kernel. You will merely need to reboot your system to use the upgraded kernel. - If Linux API headers or Glibc needs to be upgraded to a newer - version, (e.g. from glibc-2.31 to glibc-2.32), it is safer to + If Linux API headers or glibc need to be upgraded to a newer + version, (e.g., from glibc-2.31 to glibc-2.32), it is safer to rebuild LFS. Though you may be able to rebuild all the packages in their dependency order, we do not recommend it. @@ -70,44 +70,44 @@ If a package containing a shared library is updated, and if the name of the library changes, then any packages dynamically - linked to the library need to be recompiled in order to link against the + linked to the library must be recompiled, to link against the newer library. (Note that there is no correlation between the package version and the name of the library.) For example, consider a package - foo-1.2.3 that installs a shared library with name libfoo.so.1. If you upgrade the package to - a newer version foo-1.2.4 that installs a shared library with name + foo-1.2.3 that installs a shared library with the name libfoo.so.1. Suppose you upgrade the package to + a newer version foo-1.2.4 that installs a shared library with the name libfoo.so.2. In this case, any packages that are dynamically linked to libfoo.so.1 need to be recompiled to link against libfoo.so.2 in order to - use the new library version. You should not remove the previous - libraries unless all the dependent packages are recompiled. + use the new library version. You should not remove the old + libraries until all the dependent packages have been recompiled. If a package containing a shared library is updated, - and the name of library doesn't change, but the version number of the + and the name of the library doesn't change, but the version number of the library file decreases (for example, - the name of the library is kept named + the library is still named libfoo.so.1, - but the name of library file is changed from + but the name of the library file is changed from libfoo.so.1.25 to libfoo.so.1.24), you should remove the library file from the previously installed version - (libfoo.so.1.25 in the case). - Or, a ldconfig run (by yourself using a command + (libfoo.so.1.25 in this case). + Otherwise, a ldconfig command (invokeed by yourself from the command line, or by the installation of some package) will reset the symlink libfoo.so.1 to point to - the old library file because it seems having a newer - version, as its version number is larger. This situation may happen if - you have to downgrade a package, or the package changes the versioning - scheme of library files suddenly. + the old library file because it seems to be a newer + version; its version number is larger. This situation may arise if + you have to downgrade a package, or if the authors change the versioning + scheme for library files. If a package containing a shared library is updated, - and the name of library doesn't change, but a severe issue + and the name of the library doesn't change, but a severe issue (especially, a security vulnerability) is fixed, all running programs linked to the shared library should be restarted. The following command, run as root after - updating, will list what is using the old versions of those libraries + the update is cmplete, will list which processes are using the old versions of those libraries (replace libfoo with the name of the library): @@ -115,33 +115,33 @@ tr -cd 0-9\\n | xargs -r ps u - If OpenSSH is being used for accessing - the system and it is linked to the updated library, you need to - restart sshd service, then logout, login again, - and rerun that command to confirm nothing is still using the + If OpenSSH is being used to access + the system and it is linked to the updated library, you must + restart the sshd service, then logout, login again, + and rerun the preceding ps command to confirm that nothing is still using the deleted libraries. If the systemd daemon (running as PID 1) is - linked to the updated library, you can restart it without reboot + linked to the updated library, you can restart it without rebooting by running systemctl daemon-reexec as the root user. - If a binary or a shared library is overwritten, the processes - using the code or data in the binary or library may crash. The - correct way to update a binary or a shared library without causing + If an executable program or a shared library is overwritten, the processes + using the code or data in that program or library may crash. The + correct way to update a program or a shared library without causing the process to crash is to remove it first, then install the new - version into position. The install command - provided by Coreutils has already - implemented this and most packages use it to install binaries and + version. The install command + provided by coreutils has already + implemented this, and most packages use that command to install binary files and libraries. This means that you won't be troubled by this issue most of the time. However, the install process of some packages (notably Mozilla JS - in BLFS) just overwrites the file if it exists and causes a crash, so + in BLFS) just overwrites the file if it exists; this causes a crash. So it's safer to save your work and close unneeded running processes - before updating a package. + before updating a package. @@ -152,36 +152,36 @@ The following are some common package management techniques. Before making a decision on a package manager, do some research on the various - techniques, particularly the drawbacks of the particular scheme. + techniques, particularly the drawbacks of each particular scheme. It is All in My Head! - Yes, this is a package management technique. Some folks do not find - the need for a package manager because they know the packages intimately - and know what files are installed by each package. Some users also do not + Yes, this is a package management technique. Some folks do not + need a package manager because they know the packages intimately + and know which files are installed by each package. Some users also do not need any package management because they plan on rebuilding the entire - system when a package is changed. + system whenever a package is changed. Install in Separate Directories - This is a simplistic package management that does not need any extra - package to manage the installations. Each package is installed in a + This is a simplistic package management technique that does not need a + special program to manage the packages. Each package is installed in a separate directory. For example, package foo-1.1 is installed in /usr/pkg/foo-1.1 and a symlink is made from /usr/pkg/foo to - /usr/pkg/foo-1.1. When installing - a new version foo-1.2, it is installed in + /usr/pkg/foo-1.1. When + a new version foo-1.2 comes along, it is installed in /usr/pkg/foo-1.2 and the previous symlink is replaced by a symlink to the new version. Environment variables such as PATH, LD_LIBRARY_PATH, MANPATH, INFOPATH and CPPFLAGS need to be expanded to - include /usr/pkg/foo. For more than a few packages, + include /usr/pkg/foo. If you install more than a few packages, this scheme becomes unmanageable. @@ -190,15 +190,15 @@ Symlink Style Package Management This is a variation of the previous package management technique. - Each package is installed similar to the previous scheme. But instead of - making the symlink, each file is symlinked into the + Each package is installed as in the previous scheme. But instead of + making the symlink via a generic package name, each file is symlinked into the /usr hierarchy. This removes the need to expand the environment variables. Though the symlinks can be - created by the user to automate the creation, many package managers have - been written using this approach. A few of the popular ones include Stow, + created by the user, many package managers use this approach, and + automate the creation of the symlinks. A few of the popular ones include Stow, Epkg, Graft, and Depot. - The installation needs to be faked, so that the package thinks that + The installation script needs to be fooled, so the package thinks it is installed in /usr though in reality it is installed in the /usr/pkg hierarchy. Installing in @@ -216,7 +216,7 @@ make install /usr/pkg/libfoo/1.1/lib/libfoo.so.1 instead of /usr/lib/libfoo.so.1 as you would expect. The correct approach is to use the - DESTDIR strategy to fake installation of the package. This + DESTDIR variable to direct the installation. This approach works as follows: ./configure --prefix=/usr @@ -224,8 +224,8 @@ make make DESTDIR=/usr/pkg/libfoo/1.1 install Most packages support this approach, but there are some which do not. - For the non-compliant packages, you may either need to manually install the - package, or you may find that it is easier to install some problematic + For the non-compliant packages, you may either need to install the + package manually, or you may find that it is easier to install some problematic packages into /opt. @@ -237,14 +237,14 @@ make DESTDIR=/usr/pkg/libfoo/1.1 install the package. After the installation, a simple use of the find command with the appropriate options can generate a log of all the files installed after the timestamp file was created. A - package manager written with this approach is install-log. + package manager that uses this approach is install-log. Though this scheme has the advantage of being simple, it has two drawbacks. If, during installation, the files are installed with any timestamp other than the current time, those files will not be tracked by - the package manager. Also, this scheme can only be used when one package - is installed at a time. The logs are not reliable if two packages are - being installed on two different consoles. + the package manager. Also, this scheme can only be used when packages + are installed one at a time. The logs are not reliable if two packages are + installed simultaneously from two different consoles. @@ -262,12 +262,12 @@ make DESTDIR=/usr/pkg/libfoo/1.1 install calls that modify the filesystem. For this approach to work, all the executables need to be dynamically linked without the suid or sgid bit. Preloading the library may cause some unwanted side-effects during - installation. Therefore, it is advised that one performs some tests to - ensure that the package manager does not break anything and logs all the + installation. Therefore, it's a good idea to perform some tests to + ensure that the package manager does not break anything, and that it logs all the appropriate files. - The second technique is to use strace, which - logs all system calls made during the execution of the installation + Another technique is to use strace, which + logs all the system calls made during the execution of the installation scripts. @@ -275,10 +275,10 @@ make DESTDIR=/usr/pkg/libfoo/1.1 install Creating Package Archives In this scheme, the package installation is faked into a separate - tree as described in the Symlink style package management. After the + tree as previously described in the symlink style package management section. After the installation, a package archive is created using the installed files. - This archive is then used to install the package either on the local - machine or can even be used to install the package on other machines. + This archive is then used to install the package on the local + machine or even on other machines. This approach is used by most of the package managers found in the commercial distributions. Examples of package managers that follow this @@ -289,10 +289,10 @@ make DESTDIR=/usr/pkg/libfoo/1.1 install package management for LFS systems is located at . - Creation of package files that include dependency information is - complex and is beyond the scope of LFS. + The creation of package files that include dependency information is + complex, and beyond the scope of LFS. - Slackware uses a tar based system for package + Slackware uses a tar-based system for package archives. This system purposely does not handle package dependencies as more complex package managers do. For details of Slackware package management, see another computer with the same architecture as the base system is as simple as using tar on the LFS partition that contains the root directory (about 250MB uncompressed for a base LFS build), copying - that file via network transfer or CD-ROM to the new system and expanding - it. From that point, a few configuration files will have to be changed. + that file via network transfer or CD-ROM / USB stick to the new system, and expanding + it. After that, a few configuration files will have to be changed. Configuration files that may need to be updated include: /etc/hosts, /etc/fstab, @@ -342,17 +342,17 @@ make DESTDIR=/usr/pkg/libfoo/1.1 install - A custom kernel may need to be built for the new system depending on + A custom kernel may be needed for the new system, depending on differences in system hardware and the original kernel configuration. There have been some reports of issues when copying between similar but not identical architectures. For instance, the instruction set - for an Intel system is not identical with an AMD processor and later - versions of some processors may have instructions that are unavailable in + for an Intel system is not identical with the AMD processor's instructions, and later + versions of some processors may provide instructions that are unavailable with earlier versions. - Finally the new system has to be made bootable via Finally, the new system has to be made bootable via . diff --git a/chapter09/systemd-custom.xml b/chapter09/systemd-custom.xml index 22fb32525..0218b0f23 100644 --- a/chapter09/systemd-custom.xml +++ b/chapter09/systemd-custom.xml @@ -46,7 +46,7 @@ EOF - + Disabling tmpfs for /tmp By default, /tmp is created as diff --git a/chapter09/udev.xml b/chapter09/udev.xml index 435255a19..396f2b389 100644 --- a/chapter09/udev.xml +++ b/chapter09/udev.xml @@ -93,7 +93,7 @@ - + Device Node Creation Device files are created by the kernel by the EOF diff --git a/chapter10/kernel.xml b/chapter10/kernel.xml index 43b080ccb..aeffda900 100644 --- a/chapter10/kernel.xml +++ b/chapter10/kernel.xml @@ -117,7 +117,9 @@ General architecture-dependent options ---> Device Drivers ---> Graphics support ---> Frame buffer Devices ---> - [*] Support for frame buffer devices ---- + <*> Support for frame buffer devices ---> + Console display driver support ---> + [*] Framebuffer Console support [CONFIG_FRAMEBUFFER_CONSOLE] Generic Driver Options ---> [ ] Support for uevent helper [CONFIG_UEVENT_HELPER] [*] Maintain a devtmpfs filesystem to mount at /dev [CONFIG_DEVTMPFS] @@ -156,6 +158,8 @@ Device Drivers ---> Graphics support ---> Frame buffer Devices ---> <*> Support for frame buffer devices ---> + Console display driver support ---> + [*] Framebuffer Console support [CONFIG_FRAMEBUFFER_CONSOLE] File systems ---> [*] Inotify support for userspace [CONFIG_INOTIFY_USER] Pseudo filesystems ---> @@ -301,6 +305,20 @@ Device Drivers ---> + + Framebuffer Console support + + This is needed to display the Linux console on a frame + buffer device. To allow the kernel to print debug messages at an + early boot stage, it shouldn't be built as a kernel module + unless an initramfs will be used. And, if + (Direct Rendering Manager) is enabled, + it's likely (Enable + legacy fbdev support for your modesetting driver) should be + enabled as well. + + + Support x2apic @@ -349,12 +367,18 @@ Device Drivers ---> the /boot directory. - If the host system has a separate /boot partition, the files copied - below should go there. The easiest way to do that is to bind /boot on the - host (outside chroot) to /mnt/lfs/boot before proceeding. As the - &root; user in the host system: + If you've decided to use a separate &boot-dir; partition for the + LFS system (maybe sharing a &boot-dir; partition with the host + distro) , the files copied below should go there. The easiest way to + do that is to create the entry for &boot-dir; in &fstab; first (read + the previous section for details), then issue the following command + as the &root; user in the + chroot environment: -mount --bind /boot /mnt/lfs/boot +mount /boot + + The path to the device node is omitted in the command because + mount can read it from &fstab;. The path to the kernel image may vary depending on the platform being diff --git a/chapter11/afterlfs.xml b/chapter11/afterlfs.xml new file mode 100644 index 000000000..279cc1108 --- /dev/null +++ b/chapter11/afterlfs.xml @@ -0,0 +1,266 @@ + + + %general-entities; +]> + + + + + Getting Started After LFS + + + Deciding what to do next + + + Now that LFS is complete and you have a bootable system, what do you do? + The next step is to decide how to use it. Generally, there are two broad + categories to consider: workstation or server. Indeed, these categories + are not mutually exclusive. The applications needed for each category + can be combined onto a single system, but let's look at them separately + for now. + + + + A server is the simpler category. Generally this consists of a web + server such as the + Apache HTTP Server + and a database server such as + MariaDB. + However other services are possible. The operating system + embedded in a single use device falls into this category. + + + + On the other hand, a workstation is much more complex. It generally + requires a graphical user environment such as + LXDE, + XFCE, + KDE, or + Gnome + based on a basic + graphical environment + and several graphical based applications such as the + Firefox web browser, + Thunderbird email client, + or + LibreOffice office suite. + These applications require many (several hundred depending on + desired capabilities) more packages of support applications and + libraries. + + + + In addition to the above, there is a set of applications for system + management for all kinds of systems. These applications are all in the + BLFS book. Not all packages are needed in every environments. For + example dhcpcd, is + not normally appropriate for a server and wireless_tools, + are normally only useful for a laptop system. + + + + + + Working in a basic LFS environment + + + When you initially boot into LFS, you have all the internal tools to build + additional packages. Unfortunately, the user environment is quite sparse. + There are a couple of ways to improve this: + + + + Work from the LFS host in chroot + + + This method provides a complete graphical environment where a full + featured browser and copy/paste capabilities are available. This method + allows using applications like the host's version of wget to download + package sources to a location available when working in the chroot + envirnment. + + + + In order to properly build packages in chroot, you will also need to + remember to mount the virtual file systems if they are not already + mounted. One way to do this is to create a script on the + HOST system: + + +cat > ~/mount-virt.sh << "EOF" +#!/bin/bash + +function mountbind +{ + if ! mountpoint $LFS/$1 >/dev/null; then + $SUDO mount --bind /$1 $LFS/$1 + echo $LFS/$1 mounted + else + echo $LFS/$1 already mounted + fi +} + +function mounttype +{ + if ! mountpoint $LFS/$1 >/dev/null; then + $SUDO mount -t $2 $3 $4 $5 $LFS/$1 + echo $LFS/$1 mounted + else + echo $LFS/$1 already mounted + fi +} + +if [ $EUID -ne 0 ]; then + SUDO=sudo +else + SUDO="" +fi + +if [ x$LFS == x ]; then + echo "LFS not set" + exit 1 +fi + +mountbind dev +mounttype dev/pts devpts devpts -o gid=5,mode=620 +mounttype proc proc proc +mounttype sys sysfs sysfs +mounttype run tmpfs run +if [ -h $LFS/dev/shm ]; then + mkdir -pv $LFS/$(readlink $LFS/dev/shm) +else + mounttype dev/shm tmpfs tmpfs -o nosuid,nodev +fi + +#mountbind usr/src +#mountbind boot +#mountbind home +EOF + + + Note that the last three commands in the script are commented out. These + are useful if those directories are mounted as separate partitions on the + host system and will be mounted when booting the completed LFS/BLFS system. + + + + The script can be run with bash ~/mount-virt.sh as + either a regular user (recommended) or as &root;. If run as a regular + user, sudo is required on the host system. + + + + Another issue pointed out by the script is where to store downloaded + package files. This location is arbitrary. It can be in a regular + user's home directory such as ~/sources or in a global location like + /usr/src. Our recommendation is not to mix BLFS sources and LFS sources + in (from the chroot environment) /sources. In any case, the packages + must be accessible inside the chroot environment. + + + + A last convenience feature presented here is to streamline the process + of entering the chroot environment. This can be done with an alias + placed in a user's ~/.bashrc file on the host system: + + +alias lfs='sudo /usr/sbin/chroot /mnt/lfs /usr/bin/env -i HOME=/root TERM="$TERM" PS1="\u:\w\\\\$ " +PATH=/bin:/usr/bin:/sbin:/usr/sbin /bin/bash --login' + + + This alias is a little tricky because of the quoting and levels of + backslash characters. It must be all on a single line. The above command + has been split in two for presentation purposes. + + + + + + Work remotely via ssh + + + This method also provides a full graphical environment, but first + requires installing + sshd and + wget + on the LFS system, usually in chroot. It also requires a second + computer. This method has the advantage of being simple by not requiring + the complexity of the chroot environment. It also uses your LFS built + kernel for all additional packages and still provides a complete system + for installing packages. + + + + + + Work from the LFS command line + + + This method requires installing + libtasn1, + p11-kit, + make-ca, + wget, + gpm, and + links + (or lynx) + in chroot and then rebooting into the new LFS system. At this + point the default system has six virtual consoles. Switching + consoles is as easy as using the + + Alt + Fx + + key combinations where Fx is + between F1 and F6. + The + + Alt + + + and + + Alt + + + combinations also will change the console. + + + + At this point you can log into two different virtual consoles and run + the links or lynx browser in one console and bash in the other. GPM + then allows copying commands from the browser with the left mouse + button, switching consoles, and pasting into the other console. + + + + + As a side note, switching of virtual consoles can also be done from + an X Window instance with the + + Ctrl + Alt + Fx + + key combination, but the mouse copy operation does not work + between the graphical interface and a virtual console. You can + return to the X Window display with the + + Ctrl + Alt + Fx + + combination, where Fx is usually + F1 but may be F7. + + + + + + + + + diff --git a/chapter11/chapter11.xml b/chapter11/chapter11.xml index 8b4c53a1d..9adb49473 100644 --- a/chapter11/chapter11.xml +++ b/chapter11/chapter11.xml @@ -15,5 +15,6 @@ + diff --git a/chapter11/reboot.xml b/chapter11/reboot.xml index b4413f1ce..ebfb0a2b1 100644 --- a/chapter11/reboot.xml +++ b/chapter11/reboot.xml @@ -9,17 +9,22 @@ Rebooting the System + + Now that all of the software has been installed, it is time to reboot + your computer. However, there are still a few things to check. + Here are some suggestions: - Now that all of the software has been installed, it is time to reboot - your computer. However, you should be aware of a few things. The system you + + - + + + + Install any firmware needed if the + kernel driver for your hardware requires some firmware files to function + properly. + + - Install firmwares if the kernel - driver for your hardware require some firmware to function properly. - - - Finally, a review of the following configuration files - is also appropriate at this point. + + + A review of the following configuration files + is also appropriate at this point. + /etc/bashrc @@ -86,14 +98,11 @@ Now that we have said that, let's move on to booting our shiny new LFS - installation for the first time! First exit from the chroot environment: + installation for the first time! First exit from the chroot + environment: logout - + Then unmount the virtual file systems: @@ -106,17 +115,19 @@ umount -v $LFS/sys If multiple partitions were created, unmount the other partitions before unmounting the main one, like this: -umount -v $LFS/usr -umount -v $LFS/home +umount -v $LFS/home umount -v $LFS Unmount the LFS file system itself: umount -v $LFS - Now, reboot the system with: + Now, reboot the system. -shutdown -r now + + Assuming the GRUB boot loader was set up as outlined earlier, the menu is set to boot LFS &version; automatically. diff --git a/chapter11/theend.xml b/chapter11/theend.xml index 8470948a3..6f5e7e401 100644 --- a/chapter11/theend.xml +++ b/chapter11/theend.xml @@ -60,8 +60,7 @@ PRETTY_NAME="Linux From Scratch &version;" VERSION_CODENAME="<your name here>" EOF - Be sure to put some sort of customization for the fields - 'DISTRIB_CODENAME' and 'VERSION_CODENAME' to make the system uniquely - yours. + Be sure to customize the fields 'DISTRIB_CODENAME' and + 'VERSION_CODENAME' to make the system uniquely yours. diff --git a/chapter11/whatnow.xml b/chapter11/whatnow.xml index 999926289..e477e21c8 100644 --- a/chapter11/whatnow.xml +++ b/chapter11/whatnow.xml @@ -8,7 +8,7 @@ - What Now? + Additional Resources Thank you for reading this LFS book. We hope that you have found this book helpful and have learned more about the system @@ -38,7 +38,8 @@ - Open Source Security Mailing List + Open Source Security + Mailing List This is a mailing list for discussion of security flaws, concepts, and practices in the Open Source community. @@ -46,7 +47,7 @@ - + LFS Hints diff --git a/general.ent b/general.ent index f378f7e20..00eea04e1 100644 --- a/general.ent +++ b/general.ent @@ -121,6 +121,12 @@ root"> lfs"> +devtmpfs"> +/etc/fstab"> +/boot"> +"> +"> +"> %packages-entities; diff --git a/lfs-latest-git.php b/lfs-latest-git.php index 645f8e70d..32c8150ca 100644 --- a/lfs-latest-git.php +++ b/lfs-latest-git.php @@ -34,7 +34,7 @@ function find_max( $lines, $regex_match, $regex_replace ) // Isolate the version and put in an array $slice = preg_replace( $regex_replace, "$1", $line ); - if ( $slice == $line ) continue; + if ( strcmp( $slice, $line ) == 0 ) continue; array_push( $a, $slice ); } @@ -266,6 +266,15 @@ if ( $package == "zstd" ) $dirpath = "https://github.com/facebook/zstd/rel if ( $package == "elfutils" ) return find_max( $lines, "/^\d/", "/^(\d[\d\.]+\d)\/.*$/" ); + if ( $package == "iana-etc" ) + return find_max( $lines, "/^\s*20\d\d/", "/^\s+(\d+).*$/" ); + + if ( $package == "meson" ) + return find_max( $lines, "/^\s+\d\./", "/^\s+([\d\.]+)$/" ); + + if ( $package == "shadow" ) + return find_max( $lines, "/^\s+\d\./", "/^\s+([\d\.]+)$/" ); + if ( $package == "XML-Parser" ) { $max = find_max( $lines, "/$package/", "/^.*$package-([\d\._]*\d).tar.*$/" ); @@ -292,6 +301,9 @@ if ( $package == "zstd" ) $dirpath = "https://github.com/facebook/zstd/rel return str_replace( "_", ".", $max ); } + if ( $package == "libffi" ) + return find_max( $lines, "/v\d/", "/^.*v([\d\.]+)$/" ); + if ( $package == "procps-ng" ) return find_max( $lines, "/v\d/", "/^.*v([\d\.]+)$/" ); diff --git a/packages.ent b/packages.ent index 74b60c21c..42c3a2ffa 100644 --- a/packages.ent +++ b/packages.ent @@ -48,20 +48,20 @@ - - + + - + - + - + @@ -114,10 +114,10 @@ - + - + @@ -163,10 +163,10 @@ - - + + - + @@ -317,10 +317,10 @@ - + - + @@ -391,7 +391,7 @@ - + @@ -399,18 +399,18 @@ - - + + - + - - + + - + @@ -433,12 +433,12 @@ - + - + - + - + + + - + @@ -703,10 +703,10 @@ - - + + - + diff --git a/part3intro/generalinstructions.xml b/part3intro/generalinstructions.xml index ac2bcc675..f3285bc17 100644 --- a/part3intro/generalinstructions.xml +++ b/part3intro/generalinstructions.xml @@ -11,29 +11,29 @@ General Compilation Instructions - When building packages there are several assumptions made within - the instructions: + Here are some things you should know about building each package: - Several of the packages are patched before compilation, but only when + Several packages are patched before compilation, but only when the patch is needed to circumvent a problem. A patch is often needed in - both this and the following chapters, but sometimes in only one location. + both the current and the following chapters, but sometimes, when the same package + is built more than once, the patch is not needed right away. Therefore, do not be concerned if instructions for a downloaded patch seem to be missing. Warning messages about offset or fuzz may also be encountered when applying a patch. Do - not worry about these warnings, as the patch was still successfully + not worry about these warnings; the patch was still successfully applied. - During the compilation of most packages, there will be several - warnings that scroll by on the screen. These are normal and can safely be - ignored. These warnings are as they appear—warnings about + During the compilation of most packages, some + warnings will scroll by on the screen. These are normal and can safely be + ignored. These warnings are usually about deprecated, but not invalid, use of the C or C++ syntax. C standards change - fairly often, and some packages still use the older standard. This is not a - problem, but does prompt the warning. + fairly often, and some packages have not yet been updated. This is not a + serious problem, but it does cause the warnings to appear. @@ -69,25 +69,25 @@ symbolic link to gawk. /usr/bin/yacc is a - symbolic link to bison or a small script that + symbolic link to bison, or to a small script that executes bison. - To re-emphasize the build process: + Here is a synopsis of the build process. Place all the sources and patches in a directory that will be - accessible from the chroot environment such as + accessible from the chroot environment, such as /mnt/lfs/sources/. - Change to the sources directory. + Change to the /mnt/lfs/sources/ directory. For each package: @@ -97,22 +97,21 @@ to be built. In and , ensure you are the lfs user when extracting the package. - All methods to get the source code tree being built - in-position, except extracting the package tarball, are not - supported. Notably, using cp -R to copy the + Do not use any method except the tar command + to extract the source code. Notably, using the cp -R + command to copy the source code tree somewhere else can destroy links and - timestamps in the sources tree and cause building - failure. + timestamps in the source tree, and cause the build to fail. Change to the directory created when the package was extracted. - Follow the book's instructions for building the package. + Follow the instructions for building the package. - Change back to the sources directory. + Change back to the sources directory when the build is complete. Delete the extracted source directory unless instructed otherwise. diff --git a/part3intro/introduction.xml b/part3intro/introduction.xml index 6d30ffe49..03ac66a87 100644 --- a/part3intro/introduction.xml +++ b/part3intro/introduction.xml @@ -10,25 +10,25 @@ Introduction - This part is divided into three stages: first building a cross - compiler and its associated libraries; second, use this cross toolchain + This part is divided into three stages: first, building a cross + compiler and its associated libraries; second, using this cross toolchain to build several utilities in a way that isolates them from the host - distribution; third, enter the chroot environment, which further improves - host isolation, and build the remaining tools needed to build the final + distribution; and third, entering the chroot environment (which further improves + host isolation) and constructing the remaining tools needed to build the final system. - With this part begins the real work of building a new - system. It requires much care in ensuring that the instructions are - followed exactly as the book shows them. You should try to understand - what they do, and whatever your eagerness to finish your build, you should - refrain from blindly type them as shown, but rather read documentation when + This is where the real work of building a new system + begins. Be very careful to follow the instructions exactly as the book + shows them. You should try to understand what each command does, + and no matter how eager you are to finish your build, you should + refrain from blindly typing the commands as shown. Read the documentation when there is something you do not understand. Also, keep track of your typing - and of the output of commands, by sending them to a file, using the - tee utility. This allows for better diagnosing - if something gets wrong. + and of the output of commands, by using the tee utility + to send the terminal output to a file. This makes debugging easier + if something goes wrong. - The next section gives a technical introduction to the build process, - while the following one contains very + The next section is a technical introduction to the build process, + while the following one presents very important general instructions. diff --git a/part3intro/toolchaintechnotes.xml b/part3intro/toolchaintechnotes.xml index 93f27f267..16b6aafd2 100644 --- a/part3intro/toolchaintechnotes.xml +++ b/part3intro/toolchaintechnotes.xml @@ -11,26 +11,26 @@ Toolchain Technical Notes This section explains some of the rationale and technical details - behind the overall build method. It is not essential to immediately + behind the overall build method. Don't try to immediately understand everything in this section. Most of this information will be - clearer after performing an actual build. This section can be referred - to at any time during the process. + clearer after performing an actual build. Come back and re-read this chapter + at any time during the build process. The overall goal of and is to produce a temporary area that - contains a known-good set of tools that can be isolated from the host system. - By using chroot, the commands in the remaining chapters - will be contained within that environment, ensuring a clean, trouble-free + linkend="chapter-temporary-tools"/> is to produce a temporary area + containing a set of tools that are known to be good, and that are isolated from the host system. + By using the chroot command, the compilations in the remaining chapters + will be isolated within that environment, ensuring a clean, trouble-free build of the target LFS system. The build process has been designed to - minimize the risks for new readers and to provide the most educational value + minimize the risks for new readers, and to provide the most educational value at the same time. - The build process is based on the process of + This build process is based on cross-compilation. Cross-compilation is normally used - for building a compiler and its toolchain for a machine different from - the one that is used for the build. This is not strictly needed for LFS, + to build a compiler and its associated toolchain for a machine different from + the one that is used for the build. This is not strictly necessary for LFS, since the machine where the new system will run is the same as the one - used for the build. But cross-compilation has the great advantage that + used for the build. But cross-compilation has one great advantage: anything that is cross-compiled cannot depend on the host environment. @@ -39,47 +39,46 @@ - The LFS book is not, and does not contain a general tutorial to - build a cross (or native) toolchain. Don't use the command in the - book for a cross toolchain which will be used for some purpose other + The LFS book is not (and does not contain) a general tutorial to + build a cross (or native) toolchain. Don't use the commands in the + book for a cross toolchain for some purpose other than building LFS, unless you really understand what you are doing. - Cross-compilation involves some concepts that deserve a section on - their own. Although this section may be omitted in a first reading, - coming back to it later will be beneficial to your full understanding of + Cross-compilation involves some concepts that deserve a section of + their own. Although this section may be omitted on a first reading, + coming back to it later will help you gain a fuller understanding of the process. - Let us first define some terms used in this context: + Let us first define some terms used in this context. - build + The build is the machine where we build programs. Note that this machine - is referred to as the host in other - sections. + is also referred to as the host. - host + The host is the machine/system where the built programs will run. Note that this use of host is not the same as in other sections. - target + The target is only used for compilers. It is the machine the compiler - produces code for. It may be different from both build and - host. + produces code for. It may be different from both the build and + the host. As an example, let us imagine the following scenario (sometimes - referred to as Canadian Cross): we may have a + referred to as Canadian Cross): we have a compiler on a slow machine only, let's call it machine A, and the compiler - ccA. We may have also a fast machine (B), but with no compiler, and we may - want to produce code for another slow machine (C). To build a - compiler for machine C, we would have three stages: + ccA. We also have a fast machine (B), but no compiler for (B), and we + want to produce code for a third, slow machine (C). We will build a + compiler for machine C in three stages. @@ -95,24 +94,24 @@ 1AAB - build cross-compiler cc1 using ccA on machine A + Build cross-compiler cc1 using ccA on machine A. 2ABC - build cross-compiler cc2 using cc1 on machine A + Build cross-compiler cc2 using cc1 on machine A. 3BCC - build compiler ccC using cc2 on machine B + Build compiler ccC using cc2 on machine B. - Then, all the other programs needed by machine C can be compiled + Then, all the programs needed by machine C can be compiled using cc2 on the fast machine B. Note that unless B can run programs - produced for C, there is no way to test the built programs until machine - C itself is running. For example, for testing ccC, we may want to add a + produced for C, there is no way to test the newly built programs until machine + C itself is running. For example, to run a test suite on ccC, we may want to add a fourth stage: @@ -129,7 +128,7 @@ 4CCC - rebuild and test ccC using itself on machine C + Rebuild and test ccC using ccC on machine C. @@ -146,44 +145,62 @@ Implementation of Cross-Compilation for LFS - Almost all the build systems use names of the form - cpu-vendor-kernel-os referred to as the machine triplet. An astute - reader may wonder why a triplet refers to a four component - name. The reason is history: initially, three component names were enough - to designate a machine unambiguously, but with new machines and systems - appearing, that proved insufficient. The word triplet - remained. A simple way to determine your machine triplet is to run - the config.guess + All packages involved with cross compilation in the book use an + autoconf-based building system. The autoconf-based building system + accepts system types in the form cpu-vendor-kernel-os, + referred to as the system triplet. Since the vendor field is mostly + irrelevant, autoconf allows to omit it. An astute reader may wonder + why a triplet refers to a four component name. The + reason is the kernel field and the os field originiated from one + system field. Such a three-field form is still valid + today for some systems, for example + x86_64-unknown-freebsd. But for other systems, + two systems can share the same kernel but still be too different to + use a same triplet for them. For example, an Android running on a + mobile phone is completely different from Ubuntu running on an ARM64 + server, despite they are running on the same type of CPU (ARM64) and + using the same kernel (Linux). + Without an emulation layer, you cannot run an + executable for the server on the mobile phone or vice versa. So the + system field is separated into kernel and os fields to + designate these systems unambiguously. For our example, the Android + system is designated aarch64-unknown-linux-android, + and the Ubuntu system is designated + aarch64-unknown-linux-gnu. The word + triplet remained. A simple way to determine your + system triplet is to run the config.guess script that comes with the source for many packages. Unpack the binutils sources and run the script: ./config.guess and note the output. For example, for a 32-bit Intel processor the output will be i686-pc-linux-gnu. On a 64-bit - system it will be x86_64-pc-linux-gnu. + system it will be x86_64-pc-linux-gnu. On most + Linux systems the even simpler gcc -dumpmachine command + will give you similar information. - Also be aware of the name of the platform's dynamic linker, often + You should also be aware of the name of the platform's dynamic linker, often referred to as the dynamic loader (not to be confused with the standard linker ld that is part of binutils). The dynamic linker - provided by Glibc finds and loads the shared libraries needed by a + provided by package glibc finds and loads the shared libraries needed by a program, prepares the program to run, and then runs it. The name of the dynamic linker for a 32-bit Intel machine is ld-linux.so.2 and is ld-linux-x86-64.so.2 for 64-bit systems. A + class="libraryfile">ld-linux.so.2; it's ld-linux-x86-64.so.2 on 64-bit systems. A sure-fire way to determine the name of the dynamic linker is to inspect a random binary from the host system by running: readelf -l <name of binary> | grep interpreter and noting the output. The authoritative reference covering all platforms is in the - shlib-versions file in the root of the Glibc source + shlib-versions file in the root of the glibc source tree. In order to fake a cross compilation in LFS, the name of the host triplet is slightly adjusted by changing the "vendor" field in the - LFS_TGT variable. We also use the + LFS_TGT variable so it says "lfs". We also use the --with-sysroot option when building the cross linker and cross compiler to tell them where to find the needed host files. This ensures that none of the other programs built in can link to libraries on the build - machine. Only two stages are mandatory, and one more for tests: + machine. Only two stages are mandatory, plus one more for tests. @@ -199,47 +216,63 @@ 1pcpclfs - build cross-compiler cc1 using cc-pc on pc + Build cross-compiler cc1 using cc-pc on pc. 2pclfslfs - build compiler cc-lfs using cc1 on pc + Build compiler cc-lfs using cc1 on pc. 3lfslfslfs - rebuild and test cc-lfs using itself on lfs + Rebuild and test cc-lfs using cc-lfs on lfs. - In the above table, on pc means the commands are run + In the preceding table, on pc means the commands are run on a machine using the already installed distribution. On lfs means the commands are run in a chrooted environment. Now, there is more about cross-compiling: the C language is not just a compiler, but also defines a standard library. In this book, the - GNU C library, named glibc, is used. This library must - be compiled for the lfs machine, that is, using the cross compiler cc1. + GNU C library, named glibc, is used (there is an alternative, "musl"). This library must + be compiled for the LFS machine; that is, using the cross compiler cc1. But the compiler itself uses an internal library implementing complex - instructions not available in the assembler instruction set. This - internal library is named libgcc, and must be linked to the glibc + subroutines for functions not available in the assembler instruction set. This + internal library is named libgcc, and it must be linked to the glibc library to be fully functional! Furthermore, the standard library for - C++ (libstdc++) also needs being linked to glibc. The solution to this - chicken and egg problem is to first build a degraded cc1 based libgcc, - lacking some functionalities such as threads and exception handling, then - build glibc using this degraded compiler (glibc itself is not - degraded), then build libstdc++. But this last library will lack the - same functionalities as libgcc. + C++ (libstdc++) must also be linked with glibc. The solution to this + chicken and egg problem is first to build a degraded cc1-based libgcc, + lacking some functionalities such as threads and exception handling, and then + to build glibc using this degraded compiler (glibc itself is not + degraded), and also to build libstdc++. This last library will lack some of the + functionality of libgcc. - This is not the end of the story: the conclusion of the preceding + This is not the end of the story: the upshot of the preceding paragraph is that cc1 is unable to build a fully functional libstdc++, but this is the only compiler available for building the C/C++ libraries during stage 2! Of course, the compiler built during stage 2, cc-lfs, would be able to build those libraries, but (1) the build system of - GCC does not know that it is usable on pc, and (2) using it on pc - would be at risk of linking to the pc libraries, since cc-lfs is a native - compiler. So we have to build libstdc++ later, in chroot. + gcc does not know that it is usable on pc, and (2) using it on pc + would create a risk of linking to the pc libraries, since cc-lfs is a native + compiler. So we have to re-build libstdc++ later as a part of + gcc stage 2. + + In &ch-final; (or stage 3), all packages needed for + the LFS system are built. Even if a package is already installed into + the LFS system in a previous chapter, we still rebuild the package + unless we are completely sure it's unnecessary. The main reason for + rebuilding these packages is to settle them down: if we reinstall a LFS + package on a complete LFS system, the installed content of the package + should be same as the content of the same package installed in + &ch-final;. The temporary packages installed in &ch-tmp-cross; or + &ch-tmp-chroot; cannot satisify this expectation because some of them + are built without optional dependencies installed, and autoconf cannot + perform some feature checks in &ch-tmp-cross; because of cross + compilation, causing the temporary packages to lack optional features + or use suboptimal code routines. Additionally, a minor reason for + rebuilding the packages is allowing to run the testsuite. @@ -252,10 +285,10 @@ be part of the final system. Binutils is installed first because the configure - runs of both GCC and Glibc perform various feature tests on the assembler + runs of both gcc and glibc perform various feature tests on the assembler and linker to determine which software features to enable or disable. This - is more important than one might first realize. An incorrectly configured - GCC or Glibc can result in a subtly broken toolchain, where the impact of + is more important than one might realize at first. An incorrectly configured + gcc or glibc can result in a subtly broken toolchain, where the impact of such breakage might not show up until near the end of the build of an entire distribution. A test suite failure will usually highlight this error before too much additional work is performed. @@ -274,14 +307,14 @@ $LFS_TGT-gcc dummy.c -Wl,--verbose 2>&1 | grep succeeded will show all the files successfully opened during the linking. - The next package installed is GCC. An example of what can be + The next package installed is gcc. An example of what can be seen during its run of configure is: checking what assembler to use... /mnt/lfs/tools/i686-lfs-linux-gnu/bin/as checking what linker to use... /mnt/lfs/tools/i686-lfs-linux-gnu/bin/ld This is important for the reasons mentioned above. It also - demonstrates that GCC's configure script does not search the PATH + demonstrates that gcc's configure script does not search the PATH directories to find which tools to use. However, during the actual operation of gcc itself, the same search paths are not necessarily used. To find out which standard linker gcc @@ -295,12 +328,12 @@ checking what linker to use... /mnt/lfs/tools/i686-lfs-linux-gnu/bin/ld Next installed are sanitized Linux API headers. These allow the - standard C library (Glibc) to interface with features that the Linux + standard C library (glibc) to interface with features that the Linux kernel will provide. - The next package installed is Glibc. The most important - considerations for building Glibc are the compiler, binary tools, and - kernel headers. The compiler is generally not an issue since Glibc will + The next package installed is glibc. The most important + considerations for building glibc are the compiler, binary tools, and + kernel headers. The compiler is generally not an issue since glibc will always use the compiler relating to the --host parameter passed to its configure script; e.g. in our case, the compiler will be $LFS_TGT-gcc. The binary tools and kernel @@ -313,30 +346,31 @@ checking what linker to use... /mnt/lfs/tools/i686-lfs-linux-gnu/bin/ld$LFS_TGT expanded) to control which binary tools are used and the use of the -nostdinc and -isystem flags to control the compiler's include - search path. These items highlight an important aspect of the Glibc + search path. These items highlight an important aspect of the glibc package—it is very self-sufficient in terms of its build machinery and generally does not rely on toolchain defaults. - As said above, the standard C++ library is compiled next, followed in - by all the programs that need - themselves to be built. The install step of all those packages uses the - DESTDIR variable to have the - programs land into the LFS filesystem. + As mentioned above, the standard C++ library is compiled next, followed in + by other programs that need + to be cross compiled for breaking circular dependencies at build time. + The install step of all those packages uses the + DESTDIR variable to force installation + in the LFS filesystem. At the end of the native - lfs compiler is installed. First binutils-pass2 is built, - with the same DESTDIR install as the other programs, - then the second pass of GCC is constructed, omitting libstdc++ - and other non-important libraries. Due to some weird logic in GCC's + LFS compiler is installed. First binutils-pass2 is built, + in the same DESTDIR directory as the other programs, + then the second pass of gcc is constructed, omitting some + non-critical libraries. Due to some weird logic in gcc's configure script, CC_FOR_TARGET ends up as - cc when the host is the same as the target, but is + cc when the host is the same as the target, but different from the build system. This is why - CC_FOR_TARGET=$LFS_TGT-gcc is put explicitly into - the configure options. + CC_FOR_TARGET=$LFS_TGT-gcc is declared explicitly + as one of the configuration options. Upon entering the chroot environment in , the first task is to install - libstdc++. Then temporary installations of programs needed for the proper + linkend="chapter-chroot-temporary-tools"/>, + the temporary installations of programs needed for the proper operation of the toolchain are performed. From this point onwards, the core toolchain is self-contained and self-hosted. In , final versions of all the