Changeset ee714d3 for chapter04

Timestamp:

06/09/2020 09:26:11 PM (4 years ago)

Author:

Bruce Dubbs <bdubbs@…>

Branches:

10.0, 10.0-rc1, 10.1, 10.1-rc1, 11.0, 11.0-rc1, 11.0-rc2, 11.0-rc3, 11.1, 11.1-rc1, 11.2, 11.2-rc1, 11.3, 11.3-rc1, 12.0, 12.0-rc1, 12.1, 12.1-rc1, arm, bdubbs/gcc13, ml-11.0, multilib, renodr/libudev-from-systemd, s6-init, trunk, xry111/arm64, xry111/arm64-12.0, xry111/clfs-ng, xry111/lfs-next, xry111/loongarch, xry111/loongarch-12.0, xry111/loongarch-12.1, xry111/mips64el, xry111/pip3, xry111/rust-wip-20221008, xry111/update-glibc

Children:

79524a0

Parents:

b99b7d3

Message:

Text update to cross2 Chapter 4.

git-svn-id: ​http://svn.linuxfromscratch.org/LFS/branches/cross2@11913 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689

Location:

chapter04

Files:

• aboutsbus.xml (modified) (3 diffs)
• abouttestsuites.xml (modified) (1 diff)
• addinguser.xml (modified) (3 diffs)
• settingenviron.xml (modified) (3 diffs)

chapter04/aboutsbus.xml

@@ -21 +21 @@
 
   <para>The SBU measure works as follows. The first package to be compiled
-  from this book is Binutils in <xref linkend="chapter-temporary-tools"/>. The
+  from this book is binutils in <xref linkend="chapter-cross-tools"/>. 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
@@ -28 +28 @@
   <para>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
   <emphasis>approximately</emphasis> 45 minutes to build this example package.
-  Fortunately, most build times are shorter than the one for Binutils.</para>
+  Fortunately, most build times are shorter than the one for binutils.</para>
 
   <para>In general, SBUs are not entirely accurate because they depend on many
@@ -42 +42 @@
     make" by either setting an environment variable or telling the
     <command>make</command> program how many processors are available.  For
-    instance, a Core2Duo can support two simultaneous processes with:</para>
+    instance, an Intel i5-6500 COU  can support four simultaneous processes with:</para>
 
-    <screen role="nodump"><userinput>export MAKEFLAGS='-j 2'</userinput></screen>
+    <screen role="nodump"><userinput>export MAKEFLAGS='-j4'</userinput></screen>
 
     <para>or just building with:</para>
 
-    <screen role="nodump"><userinput>make -j2</userinput></screen>
+    <screen role="nodump"><userinput>make -j4</userinput></screen>
 
     <para>When multiple processors are used in this way, the SBU units in the

chapter04/abouttestsuites.xml

@@ -19 +19 @@
 
   <para>Some test suites are more important than others. For example,
-  the test suites for the core toolchain packages&mdash;GCC, Binutils, and
-  Glibc&mdash;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&mdash;GCC, binutils, and
+  glibc&mdash;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.</para>
 
   <note>
-    <para>Running the test suites in <xref linkend="chapter-temporary-tools"/>
+    <para>Running the test suites in <xref linkend="chapter-cross-tools"/>
+    and <xref linkend="chapter-temporary-tools"/>
     is impossible, since the programs are compiled with a cross-compiler,
     so are not supposed to be able to run on the build host.</para>
   </note>
 
-  <para>A common issue with running the test suites for Binutils and GCC
+  <para>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

chapter04/addinguser.xml

@@ -12 +12 @@
 
   <para>When logged in as user <systemitem class="username">root</systemitem>,
-  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 <systemitem
@@ -63 +63 @@
       <term><parameter>lfs</parameter></term>
       <listitem>
-        <para>This is the actual name for the created group and user.</para>
+        <para>This is the actual name for the created user.</para>
       </listitem>
     </varlistentry>
@@ -96 +96 @@
   <para>Next, login as user <systemitem class="username">lfs</systemitem>.
   This can be done via a virtual console, through a display manager, or with
-  the following substitute user command:</para>
+  the following substitute/switch user command:</para>
 
 <screen role="nodump"><userinput>su - lfs</userinput></screen>

chapter04/settingenviron.xml

@@ -51 +51 @@
 
   <variablelist>
-    <title>The meaning of the command line options in <filename>.bashrc</filename></title>
+    <title>The meaning of the settings in <filename>.bashrc</filename></title>
 
     <varlistentry>
@@ -137 +137 @@
   <para>By putting <filename class="directory">$LFS/tools/bin</filename> ahead of the
   standard <envar>PATH</envar>, the cross-compiler installed at the beginning
-  of <xref linkend="chapter-temporary-tools"/> is picked up by the shell
+  of <xref linkend="chapter-cross-tools"/> 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
@@ -148 +148 @@
       <listitem>
         <para>While the above commands have set some variables, in order
-        to make them visible within any sub-shells, we export them</para>
+        to make them visible within any sub-shells, we export them.</para>
       </listitem>
     </varlistentry>