diff --git a/chapter04/aboutlfs.xml b/chapter04/aboutlfs.xml index d97f634b0..14aec3126 100644 --- a/chapter04/aboutlfs.xml +++ b/chapter04/aboutlfs.xml @@ -1,35 +1,39 @@ - %general-entities; ]> - -About $LFS - -Throughout this book, the environment variable LFS will -be used several times. It is paramount that this variable is always defined. -It should be set to the mount point chosen for the LFS partition. -Check that the LFS variable is set up properly with: + + + + About $LFS + + Throughout this book, the environment variable LFS will + be used several times. It is paramount that this variable is always defined. + It should be set to the mount point chosen for the LFS partition. + Check that the LFS variable is set up properly with: echo $LFS -Make sure the output shows the path to the LFS partition's mount -point, which is /mnt/lfs if the -provided example was followed. If the output is incorrect, the -variable can be set with: + Make sure the output shows the path to the LFS partition's mount + point, which is /mnt/lfs if the + provided example was followed. If the output is incorrect, the + variable can be set with: export LFS=/mnt/lfs -Having this variable set is beneficial in that commands such as -mkdir $LFS/tools can be typed literally. The shell -will automatically replace $LFS with -/mnt/lfs (or whatever the variable was set to) when it -processes the command line. + Having this variable set is beneficial in that commands such as + mkdir $LFS/tools can be typed literally. The shell + will automatically replace $LFS with + /mnt/lfs (or whatever the variable was set to) when it + processes the command line. -Do not forget to check that $LFS is set whenever -you leave and reenter the current working environment (as when doing a -su to root or another user). + Do not forget to check that $LFS is set whenever + you leave and reenter the current working environment (as when doing a + su to root + or another user). diff --git a/chapter04/aboutsbus.xml b/chapter04/aboutsbus.xml index 28d83c01c..8383c6ffe 100644 --- a/chapter04/aboutsbus.xml +++ b/chapter04/aboutsbus.xml @@ -1,42 +1,45 @@ - %general-entities; ]> + -About SBUs - + -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 -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. + About SBUs -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. + 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 + 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. -For example, consider a package whose compilation time is 4.5 -SBUs. This means that if a 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. + 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. -In general, SBUs are not entirely accurate because they depend on many -factors, including the host system's version of GCC. Note that on Symmetric -Multi-Processor (SMP)-based machines, SBUs are even less accurate. 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. + For example, consider a package whose compilation time is 4.5 + SBUs. This means that if a 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. -To view actual timings for a number of specific machines, we recommend -The LinuxFromScratch SBU Home Page at . + In general, SBUs are not entirely accurate because they depend on many + factors, including the host system's version of GCC. Note that on Symmetric + Multi-Processor (SMP)-based machines, SBUs are even less accurate. 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. + + To view actual timings for a number of specific machines, we recommend + The LinuxFromScratch SBU Home Page at . diff --git a/chapter04/abouttestsuites.xml b/chapter04/abouttestsuites.xml index 19993637d..1a08bedea 100644 --- a/chapter04/abouttestsuites.xml +++ b/chapter04/abouttestsuites.xml @@ -1,50 +1,52 @@ - %general-entities; ]> + -About the Test Suites - + -Most packages provide a test suite. Running the test suite for a -newly built package is a good idea because it can provide a sanity -check indicating that everything compiled correctly. A test suite -that passes its set of checks usually proves that the package is -functioning as the developer intended. It does not, however, guarantee -that the package is totally bug free. + About the Test Suites -Some test suites are more important than others. For example, -the test suites for the core toolchain packages—GCC, Binutils, and -Glibc—are of the utmost importance due to their central role in a -properly functioning system. The test suites for GCC and Glibc can -take a very long time to complete, especially on slower hardware, but -are strongly recommended. + Most packages provide a test suite. Running the test suite for a + newly built package is a good idea because it can provide a sanity + check indicating that everything compiled correctly. A test suite + that passes its set of checks usually proves that the package is + functioning as the developer intended. It does not, however, guarantee + that the package is totally bug free. -Experience has shown that there is little to be gained -from running the test suites in . There can be no escaping the fact -that the host system always exerts some influence on the tests in that -chapter, often causing inexplicable failures. Because the tools built -in are temporary and -eventually discarded, we do not recommend running the test suites in - for the average reader. The -instructions for running those test suites are provided for the -benefit of testers and developers, but they are strictly -optional. + Some test suites are more important than others. For example, + the test suites for the core toolchain packages—GCC, Binutils, and + Glibc—are of the utmost importance due to their central role in a + properly functioning system. The test suites for GCC and Glibc can + take a very long time to complete, especially on slower hardware, but + are strongly recommended. -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 -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 in . + + Experience has shown that there is little to be gained from running + the test suites in . There can be + no escaping the fact that the host system always exerts some influence on + the tests in that chapter, often causing inexplicable failures. Because + the tools built in are temporary + and eventually discarded, we do not recommend running the test suites in + for the average reader. The + instructions for running those test suites are provided for the benefit of + testers and developers, but they are strictly optional. + -Sometimes package test suites will fail, but 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. + 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 + 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 in . + + Sometimes package test suites will fail, but 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. - diff --git a/chapter04/addinguser.xml b/chapter04/addinguser.xml index 7cb703824..5a1a2d3fa 100644 --- a/chapter04/addinguser.xml +++ b/chapter04/addinguser.xml @@ -1,90 +1,102 @@ - %general-entities; ]> - -Adding the LFS User - -When logged in as user root, making a single mistake -can damage or destroy a system. Therefore, we recommend building the packages in -this chapter 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 the installation process. As -root, issue the following commands to add the new -user: + + + + Adding the LFS User + + When logged in as user root, + making a single mistake can damage or destroy a system. Therefore, we + recommend building the packages in this chapter 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 + the installation process. As root, + issue the following commands to add the new user: groupadd lfs useradd -s /bin/bash -g lfs -m -k /dev/null lfs -The meaning of the command line options: + + The meaning of the command line options: - - --s /bin/bash -This makes -bash the default shell for user -lfs. - + + -s /bin/bash + + This makes bash the default shell for user + lfs. + + - --g lfs -This option adds user lfs to group -lfs. - + + -g lfs + + This option adds user lfs + to group lfs. + + - --m -This creates a home -directory for lfs. - + + -m + + This creates a home directory for lfs. + + - --k /dev/null -This parameter -prevents possible copying of files from a skeleton directory (default -is /etc/skel) by changing the input location to -the special null device. - + + -k /dev/null + + This parameter prevents possible copying of files from a skeleton + directory (default is /etc/skel) + by changing the input location to the special null device. + + - -lfs -This is the actual name for the created group and -user. - - + + lfs + + This is the actual name for the created group and user. + + -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: + + + 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: passwd lfs -Grant lfs full access to -$LFS/tools by making -lfs the directory owner: + Grant lfs full access to + $LFS/tools by making + lfs the directory owner: chown -v lfs $LFS/tools -If a separate working directory was created as suggested, give -user lfs ownership of this directory: + If a separate working directory was created as suggested, give + user lfs ownership of this + directory: chown -v lfs $LFS/sources -Next, login as user lfs. This can be done -via a virtual console, through a display manager, or with the -following substitute user command: + Next, login as user lfs. + This can be done via a virtual console, through a display manager, or with + the following substitute user command: -su - lfs +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 -bash(1) and info bash. + 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 + bash(1) and info bash. - diff --git a/chapter04/chapter04.xml b/chapter04/chapter04.xml index 689932619..b5ef385c6 100644 --- a/chapter04/chapter04.xml +++ b/chapter04/chapter04.xml @@ -1,18 +1,21 @@ - %general-entities; ]> - - -Final Preparations - - - - - - - + + + + + Final Preparations + + + + + + + diff --git a/chapter04/creatingtoolsdir.xml b/chapter04/creatingtoolsdir.xml index bed68fb17..50fa9aa25 100644 --- a/chapter04/creatingtoolsdir.xml +++ b/chapter04/creatingtoolsdir.xml @@ -1,46 +1,48 @@ - %general-entities; ]> + -Creating the $LFS/tools Directory - + -All programs compiled in will be installed under $LFS/tools to keep them separate from the -programs compiled in . The -programs compiled here are temporary tools and will not be a part of -the final LFS system. By keeping these programs in a separate -directory, they can easily be discarded later after their use. This -also prevents these programs from ending up in the host production -directories (easy to do by accident in ). + Creating the $LFS/tools Directory -Create the required directory by running the following as -root: + All programs compiled in + will be installed under $LFS/tools + to keep them separate from the programs compiled in . The programs compiled here are + temporary tools and will not be a part of the final LFS system. By keeping + these programs in a separate directory, they can easily be discarded later + after their use. This also prevents these programs from ending up in the + host production directories (easy to do by accident in ). + + Create the required directory by running the following as + root: mkdir -v $LFS/tools -The next step is to create a /tools -symlink on the host system. This will point to the newly-created directory on -the LFS partition. Run this command as root as -well: + The next step is to create a /tools + symlink on the host system. This will point to the newly-created directory on + the LFS partition. Run this command as root as well: ln -sv $LFS/tools / -The above command is correct. The ln command has -a few syntactic variations, so be sure to check info coreutils ln and -ln(1) before reporting what you may think is an -error. + + The above command is correct. The ln command + has a few syntactic variations, so be sure to check + info coreutils ln and ln(1) + before reporting what you may think is an error. + -The created symlink enables the toolchain to be compiled so that -it always refers to /tools, -meaning that the compiler, assembler, and linker will work both in -this chapter (when we are still using some tools from the host) and in -the next (when we are chrooted to the LFS -partition). + The created symlink enables the toolchain to be compiled so that it + always refers to /tools, meaning + that the compiler, assembler, and linker will work both in this chapter + (when we are still using some tools from the host) and in the next (when + we are chrooted to the LFS partition). - diff --git a/chapter04/settingenviron.xml b/chapter04/settingenviron.xml index 574526392..561e30381 100644 --- a/chapter04/settingenviron.xml +++ b/chapter04/settingenviron.xml @@ -1,40 +1,41 @@ - %general-entities; ]> - -Setting Up the Environment - -Set up a good working environment by creating two new startup -files for the bash shell. While logged in as user -lfs, issue the -following command to create a new .bash_profile: + + + + Setting Up the Environment + + Set up a good working environment by creating two new startup files + for the bash shell. While logged in as user + lfs, issue the following command + to create a new .bash_profile: cat > ~/.bash_profile << "EOF" 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 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 -.bash_profile file replaces the running shell -with a new one with a completely empty environment, except for the -HOME, TERM, and -PS1 variables. This ensures that no unwanted and -potentially hazardous environment variables from the host system leak -into the build environment. The technique used here achieves the goal -of ensuring a clean environment. + When logged on as user lfs, + the initial shell is usually 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 + .bash_profile file replaces the running shell with a new + one with a completely empty environment, except for the HOME, + TERM, and PS1 variables. This ensures that no + unwanted and potentially hazardous environment variables from the host system + leak into the build environment. The technique used here achieves the goal of + ensuring a clean environment. -The new instance of the shell is a non-login -shell, which does not read the /etc/profile or -.bash_profile files, but rather reads the -.bashrc file instead. Create the -.bashrc file now: + The new instance of the shell is a non-login + shell, which does not read the /etc/profile or + .bash_profile files, but rather reads the + .bashrc file instead. Create the + .bashrc file now: cat > ~/.bashrc << "EOF" set +h @@ -45,48 +46,46 @@ PATH=/tools/bin:/bin:/usr/bin export LFS LC_ALL PATH 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 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 run. As such, the shell will find the newly compiled -tools in $LFS/tools as soon as -they are available without remembering a previous version of the same -program in a different location. + 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 + 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 run. As such, the shell will find the newly compiled tools in + $LFS/tools as soon as they are + available without remembering a previous version of the same program in a + different location. -Setting the user file-creation mask (umask) to 022 ensures that newly -created files and directories are only writable by their owner, but -are readable and executable by anyone (assuming default modes are used -by the open(2) system call, new files will end up with permission mode -644 and directories with mode 755). + Setting the user file-creation mask (umask) to 022 ensures that newly + created files and directories are only writable by their owner, but are + readable and executable by anyone (assuming default modes are used by the + open(2) system call, new files will end up with permission + mode 644 and directories with mode 755). -The LFS variable should be set to the -chosen mount point. + The LFS variable should be set to the chosen mount + point. -The LC_ALL variable controls the -localization of certain programs, making their messages follow the -conventions of a specified country. If the host system uses a version -of Glibc older than 2.2.4, having LC_ALL set to something other than -POSIX or C (during this chapter) may -cause issues if you exit the chroot environment and wish to return -later. Setting LC_ALL to POSIX -or C (the two are equivalent) ensures that -everything will work as expected in the chroot environment. + The LC_ALL variable controls the localization of certain + programs, making their messages follow the conventions of a specified country. + If the host system uses a version of Glibc older than 2.2.4, having + LC_ALL set to something other than POSIX or + C (during this chapter) may cause issues if you exit the chroot + environment and wish to return later. Setting LC_ALL to + POSIX or C (the two are equivalent) ensures that + everything will work as expected in the chroot environment. -By putting /tools/bin ahead of the -standard PATH, all the programs installed in are picked up by the shell immediately after -their installation. This, combined with turning off hashing, limits the risk -that old programs are used from the host when the same programs are available in -the chapter 5 environment. + By putting /tools/bin ahead of the + standard PATH, all the programs installed in are picked up by the shell immediately after + their installation. This, combined with turning off hashing, limits the risk + that old programs are used from the host when the same programs are available in + the chapter 5 environment. -Finally, to have the environment fully prepared for building the -temporary tools, source the just-created user profile: + Finally, to have the environment fully prepared for building the + temporary tools, source the just-created user profile: source ~/.bash_profile -