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

@@ -20,16 +20,16 @@
   used instead.</para>
 
   <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
   to this time.</para>
 
   <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
   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
     <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
     book will vary even more than they normally would.  In some cases, the make

chapter04/abouttestsuites.xml

@@ -18,19 +18,20 @@
   that the package is totally bug free.</para>
 
   <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
   most likely cause is that the host system does not have the

chapter04/addinguser.xml

@@ -11,8 +11,8 @@
   <title>Adding the LFS User</title>
 
   <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
   class="username">lfs</systemitem> as a member of a new group (also named
@@ -62,7 +62,7 @@ useradd -s /bin/bash -g lfs -m -k /dev/null lfs</userinput></screen>
     <varlistentry>
       <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>
 
@@ -95,7 +95,7 @@ useradd -s /bin/bash -g lfs -m -k /dev/null lfs</userinput></screen>
 
   <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

@@ -50,7 +50,7 @@ export LFS LC_ALL LFS_TGT PATH</literal>
 EOF</userinput></screen>
 
   <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>
       <term><parameter>set +h</parameter></term>
@@ -136,7 +136,7 @@ EOF</userinput></screen>
       <listitem>
   <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
   cross-compiler.</para>
@@ -147,7 +147,7 @@ EOF</userinput></screen>
       <term><parameter>export LFS LC_ALL LFS_TGT PATH</parameter></term>
       <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>