From ee714d385e3f3b943e3fa4407847cfdeb8a435f7 Mon Sep 17 00:00:00 2001 From: Bruce Dubbs Date: Tue, 9 Jun 2020 21:26:11 +0000 Subject: [PATCH] Text update to cross2 Chapter 4. git-svn-id: http://svn.linuxfromscratch.org/LFS/branches/cross2@11913 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689 --- chapter04/aboutsbus.xml | 12 ++++++------ chapter04/abouttestsuites.xml | 11 ++++++----- chapter04/addinguser.xml | 8 ++++---- chapter04/settingenviron.xml | 6 +++--- 4 files changed, 19 insertions(+), 18 deletions(-) diff --git a/chapter04/aboutsbus.xml b/chapter04/aboutsbus.xml index 68e25cce2..646fe2875 100644 --- a/chapter04/aboutsbus.xml +++ b/chapter04/aboutsbus.xml @@ -20,16 +20,16 @@ used instead. The SBU measure works as follows. The first package to be compiled - from this book is Binutils in . The + 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. 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 + 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. + Fortunately, most build times are shorter than the one for binutils. In general, SBUs are not entirely accurate because they depend on many factors, including the host system's version of GCC. They are provided here @@ -41,13 +41,13 @@ compilation time for a package can be reduced by performing a "parallel make" by either setting an environment variable or telling the make program how many processors are available. For - instance, a Core2Duo can support two simultaneous processes with: + instance, an Intel i5-6500 COU can support four simultaneous processes with: - export MAKEFLAGS='-j 2' + export MAKEFLAGS='-j4' or just building with: - make -j2 + 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 diff --git a/chapter04/abouttestsuites.xml b/chapter04/abouttestsuites.xml index 780216181..9206f33be 100644 --- a/chapter04/abouttestsuites.xml +++ b/chapter04/abouttestsuites.xml @@ -18,19 +18,20 @@ that the package is totally bug free. 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 + 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. - Running the test suites in + 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. - A common issue with running the test suites for Binutils and GCC + 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 diff --git a/chapter04/addinguser.xml b/chapter04/addinguser.xml index 24cdb3aab..7ee10bef0 100644 --- a/chapter04/addinguser.xml +++ b/chapter04/addinguser.xml @@ -11,8 +11,8 @@ 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 the next chapter as an unprivileged user. + 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 @@ -62,7 +62,7 @@ useradd -s /bin/bash -g lfs -m -k /dev/null lfs lfs - This is the actual name for the created group and user. + This is the actual name for the created user. @@ -95,7 +95,7 @@ useradd -s /bin/bash -g lfs -m -k /dev/null lfs Next, login as user lfs. This can be done via a virtual console, through a display manager, or with - the following substitute user command: + the following substitute/switch user command: su - lfs diff --git a/chapter04/settingenviron.xml b/chapter04/settingenviron.xml index 39dcdfa3d..9c8bae7a9 100644 --- a/chapter04/settingenviron.xml +++ b/chapter04/settingenviron.xml @@ -50,7 +50,7 @@ export LFS LC_ALL LFS_TGT PATH EOF - The meaning of the command line options in <filename>.bashrc</filename> + The meaning of the settings in <filename>.bashrc</filename> set +h @@ -136,7 +136,7 @@ EOF By putting $LFS/tools/bin ahead of the standard PATH, the cross-compiler installed at the beginning - of is picked up by the shell + 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 cross-compiler. @@ -147,7 +147,7 @@ EOF export LFS LC_ALL LFS_TGT PATH While the above commands have set some variables, in order - to make them visible within any sub-shells, we export them + to make them visible within any sub-shells, we export them.