Minor textual shuffles.

git-svn-id: http://svn.linuxfromscratch.org/LFS/trunk/BOOK@3261 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689

10 files changed, 145 insertions, 149 deletions

diff --git a/chapter05/binutils-pass1.xml b/chapter05/binutils-pass1.xml
index 25cc593f4..13eac6710 100644
--- a/chapter05/binutils-pass1.xml
+++ b/chapter05/binutils-pass1.xml
@@ -17,11 +17,11 @@
 because both Glibc and GCC perform various tests on the available linker and
 assembler to determine which of their own features to enable.</para>
 
-<para>This package is known to behave badly when you have changed its default
-optimization flags (including the -march and -mcpu options). Therefore, if
-you have defined any environment variables that override default
-optimizations, such as CFLAGS and CXXFLAGS, we recommend unsetting or
-modifying them when building Binutils.</para>
+<para>This package is known to behave badly when you change its default
+optimization flags (including the <emphasis>-march</emphasis> and
+<emphasis>-mcpu</emphasis> options). Therefore, if you have defined any
+environment variables that override default optimizations, such as CFLAGS and
+CXXFLAGS, we recommend unsetting them when building Binutils.</para>
 
 <para>The Binutils documentation recommends building Binutils outside of the
 source directory in a dedicated build directory:</para>
@@ -30,9 +30,11 @@ source directory in a dedicated build directory:</para>
 cd ../binutils-build</userinput></screen>
 
 <note><para>If you want the SBU values listed in the rest of the book to be of
-any use, you will have to measure the time it takes to build this package. To
-achieve this easily, you could do something like:
-<userinput>time { ./configure ... &amp;&amp; ... &amp;&amp; ... &amp;&amp; make install; }</userinput>.</para></note>
+any use, you will have to measure the time it takes to build this package --
+from the configuration upto and including the first install. To achieve this
+easily, you could wrap the four commands in a <command>time</command> command
+like this: <userinput>time { ./configure ... &amp;&amp; ... &amp;&amp; ...
+&amp;&amp; make install; }</userinput>.</para></note>
 
 <para>Now prepare Binutils for compilation:</para>
 
@@ -66,18 +68,16 @@ problem.</para></listitem>
 
 <listitem><para><userinput>LDFLAGS="-all-static"</userinput>: This tells the
 linker that all the Binutils programs should be linked statically. However,
-strictly speaking, <emphasis>"-all-static"</emphasis> is first passed to the
-<command>libtool</command> program which then passes
-<emphasis>"-static"</emphasis> on to the linker.</para></listitem>
+strictly speaking, <emphasis>"-all-static"</emphasis> is passed to the
+<command>libtool</command> program, which then passes
+<emphasis>"-static"</emphasis> to the linker.</para></listitem>
 </itemizedlist>
 
-<para>Compilation is now complete. This is the point where we would normally
-run the test suite. But as discussed earlier, we don't recommend running the
-test suites for the temporary tools here in this chapter. However, even if we
-still wanted to run the Binutils test suite, we're unable do so at this early
-stage because the test suite framework is not yet in place. Not only that, the
-programs from this first pass will soon be overwritten by those installed in
-the second pass.</para>
+<para>Compilation is complete. Normally we would now run the test suite, but
+at this early stage the test suite framework (Tcl, Expect and DejaGnu) is not
+yet in place. And there would be little point in running the tests anyhow,
+since the programs from this first pass will soon be replaced by those from the
+second.</para>
 
 <para>And install the package:</para>
 
@@ -92,16 +92,16 @@ make -C ld LDFLAGS="-all-static" LIB_PATH=/tools/lib</userinput></screen>
 
 <itemizedlist>
 <listitem><para><userinput>-C ld clean</userinput>: This tells the make program
-to remove all the compiled files, but only in the <filename>ld</filename>
-subdirectory.</para></listitem>
-
-<listitem><para><userinput>-C ld LDFLAGS="-all-static" LIB_PATH=/tools/lib</userinput>:
-This option rebuilds everything in the <filename>ld</filename> subdirectory.
-Specifying the LIB_PATH makefile variable on the command line allows us to
-override the default value and have it point to our temporary tools location.
-The value of this variable specifies the linker's default library search path.
-You'll see how this preparation is used later on in the
-chapter.</para></listitem>
+to remove all the compiled files in the <filename
+class="directory">ld</filename> subdirectory.</para></listitem>
+
+<listitem><para><userinput>-C ld LDFLAGS="-all-static"
+LIB_PATH=/tools/lib</userinput>: This option rebuilds everything in the
+<filename class="directory">ld</filename> subdirectory. Specifying the LIB_PATH
+makefile variable on the command line allows us to override the default value
+and have it point to our temporary tools location. The value of this variable
+specifies the linker's default library search path. You will see how this
+preparation is used later on in the chapter.</para></listitem>
 </itemizedlist>
 
 <!-- HACK - Force some whitespace to appease tidy -->
diff --git a/chapter05/binutils-pass2.xml b/chapter05/binutils-pass2.xml
index b77e9dac5..2ccd0bf68 100644
--- a/chapter05/binutils-pass2.xml
+++ b/chapter05/binutils-pass2.xml
@@ -8,7 +8,6 @@
 &aa-binutils-down;
 &aa-binutils-dep;
 
-
 <sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
 
 <sect2>
@@ -28,9 +27,10 @@ cd ../binutils-build</userinput></screen>
 
 <itemizedlist>
 <listitem><para><userinput>--with-lib-path=/tools/lib</userinput>: This tells
-the configure script to specify the default library search path. We don't want
-the library search path to contain library directories from the host
-system.</para></listitem>
+the configure script to specify the library search path during the compilation
+of Binutils, resulting in <emphasis>/tools/lib</emphasis> to be passed to the
+linker. This prevents the linker from searching through library directories on
+the host.</para></listitem>
 </itemizedlist>
 
 <para>Before starting to build Binutils, remember to unset any environment
@@ -41,16 +41,16 @@ variables that override the default optimization flags.</para>
 <screen><userinput>make</userinput></screen>
 
 <para>Compilation is now complete. As discussed earlier, we don't recommend
-running the test suites for the temporary tools here in this chapter. If you
-still want to run the Binutils test suite anyway, the following command will
-do so:</para>
+running the test suites for the temporary tools here in this chapter. If
+nevertheless you want to run the Binutils test suite, the following command
+will do so:</para>
 
 <screen><userinput>make check</userinput></screen>
 
 <para>There should be no unexpected failures here, expected failures are fine.
-Unfortunately, there is no easy way to view the test results summary like
-there was for the previous GCC package. However, if a failure occurs here, it
-should be easy to spot. The output shown will contain something like:</para>
+Unfortunately, there is no easy way to view the test results summary like there
+was for the GCC package. However, if a failure occurs here, it should be easy
+to spot. The output shown will contain something like:</para>
 
 <blockquote><screen>make[1]: *** [check-binutils] Error 2</screen></blockquote>
 
diff --git a/chapter05/chapter05.xml b/chapter05/chapter05.xml
index 0e89c5944..9217c1831 100644
--- a/chapter05/chapter05.xml
+++ b/chapter05/chapter05.xml
@@ -512,13 +512,15 @@ cc dummy.c
 readelf -l a.out | grep ': /tools'</userinput></screen>
 
 <para>If everything is working correctly, there should be no errors, and the
-output of the last command will be:</para>
+output of the last command will be (allowing for platform specific differences
+in dynamic linker name):</para>
 
 <blockquote><screen>[Requesting program interpreter: /tools/lib/ld-linux.so.2]</screen></blockquote>
 
-<para>(Of course allowing for platform specific differences in dynamic linker
-name). Note especially that <filename class="directory">/tools/lib</filename>
-appears as the prefix of our dynamic linker. If you did not receive the output
+<para>Note especially that <filename class="directory">/tools/lib</filename>
+appears as the prefix of our dynamic linker.</para>
+
+<para>If you did not receive the output
 as shown above, or received no output at all, then something is seriously wrong.
 You will need to investigate and retrace your steps to find out where the
 problem is and correct it. There is no point in continuing until this is done.
diff --git a/chapter05/coreutils.xml b/chapter05/coreutils.xml
index 6672e18d5..945a129bb 100644
--- a/chapter05/coreutils.xml
+++ b/chapter05/coreutils.xml
@@ -17,16 +17,16 @@ And for the patch:
 <sect2>
 <title>Installation of Coreutils</title>
 
-<para>Coreutils has an issue when compiled against Glibc-&glibc-version;.
-Without the patch below, some of the Coreutils utilities
-(<command>head</command>, <command>tail</command>, <command>sort</command>,
-and others) will reject their traditional syntax which has been in use for
+<para>This package has an issue when compiled against Glibc-&glibc-version;.
+Without the patch below, some of the Coreutils utilities (such as
+(<command>head</command>, <command>tail</command> and <command>sort</command>)
+will reject their traditional syntax, a syntax that has been in use for
 approximately 30 years. This old syntax is so pervasive that compatibility
-should be preserved until the many places where it is used can be updated.
-More details on this are provided in the comments inside the patch itself. Use
-of this patch is by no means compulsory, but not using it means you'll have to
-deal with the consequences yourself: patch the many packages that use the old
-syntax. Therefore, better apply the patch:</para>
+should be preserved until the many places where it is used can be updated. More
+details on this are provided in the comments inside the patch itself. Use of
+this patch is by no means compulsory, but not using it means you'll have to
+deal with the consequences yourself: patch the many packages that still use the
+old syntax. Therefore, better apply the patch:</para>
 
 <screen><userinput>patch -Np1 -i ../&coreutils-posixver-patch;</userinput></screen>
 
diff --git a/chapter05/expect.xml b/chapter05/expect.xml
index 5cdcba409..752fcb977 100644
--- a/chapter05/expect.xml
+++ b/chapter05/expect.xml
@@ -16,13 +16,11 @@ other interactive programs.</para>
 <sect2>
 <title>Installation of Expect</title>
 
-<para>First apply a patch:</para>
+<para>First fix a bug that can result in bogus failures during the GCC test
+suite run:</para>
 
 <screen><userinput>patch -Np1 -i ../&expect-patch;</userinput></screen>
 
-<para>This fixes a bug in Expect that can result in bogus failures during the
-GCC test suite run.</para>
-
 <para>Now prepare Expect for compilation:</para>
 
 <screen><userinput>./configure --prefix=/tools --with-tcl=/tools/lib --with-x=no</userinput></screen>
@@ -57,8 +55,8 @@ considered critical.)</para>
 <para>The meaning of the make parameter:</para>
 
 <itemizedlist>
-<listitem><para><userinput>SCRIPTS=""</userinput>: This prevents installation of
-the supplementary expect scripts which are not needed.</para></listitem>
+<listitem><para><userinput>SCRIPTS=""</userinput>: This prevents installation
+of the supplementary expect scripts which are not needed.</para></listitem>
 </itemizedlist>
 
 <para>You can now remove the source directories of both Tcl and Expect.</para>
diff --git a/chapter05/gcc-pass1.xml b/chapter05/gcc-pass1.xml
index 08822cbf0..6cb01b4fa 100644
--- a/chapter05/gcc-pass1.xml
+++ b/chapter05/gcc-pass1.xml
@@ -15,14 +15,14 @@
 <sect2>
 <title>Installation of GCC</title>
 
-<para>Unpack only the GCC-core tarball, as we won't be needing a C++ compiler
-for the moment.</para>
+<para>Unpack only the GCC-core tarball, as we won't be needing the C++ compiler
+nor the test suite at the moment.</para>
 
-<para>This package is known to behave badly when you have changed its
-default optimization flags (including the -march and -mcpu options).
-Therefore, if you have defined any environment variables that override
-default optimizations, such as CFLAGS and CXXFLAGS, we recommend unsetting
-or modifying them when building GCC.</para>
+<para>This package is known to behave badly when you change its default
+optimization flags (including the <emphasis>-march</emphasis> and
+<emphasis>-mcpu</emphasis> options). Therefore, if you have defined any
+environment variables that override default optimizations, such as CFLAGS and
+CXXFLAGS, we recommend unsetting them when building GCC.</para>
 
 <para>The GCC documentation recommends building GCC outside of the source
 directory in a dedicated build directory:</para>
@@ -52,8 +52,8 @@ seem counter-intuitive at first. But using it allows the building of
 having <filename>libgcc_eh.a</filename> available ensures that the configure
 script for Glibc (the next package we compile) produces the proper results.
 Note that the <command>gcc</command> binaries will still be linked
-statically, as this is controlled by the <command>-static</command>
-value of BOOT_LDFLAGS further on.</para></listitem>
+statically, as this is controlled by the <emphasis>-static</emphasis>
+value of BOOT_LDFLAGS in the next step.</para></listitem>
 
 <listitem><para><userinput>--enable-languages=c</userinput>: This option
 ensures that only the C compiler is built. The option is only needed when you
@@ -78,21 +78,17 @@ reproduce itself flawlessly, which most probably means that it was
 compiled correctly.</para></listitem>
 </itemizedlist>
 
-<para>Compilation is now complete. This is the point where we would normally
-run the test suite. But as discussed earlier, we don't recommend running the
-test suites for the temporary tools here in this chapter. However, even if we
-still wanted to run the GCC test suite, we're unable do so at this early stage
-because the test suite framework is not yet in place. Not only that, the
-programs from this first pass will soon be overwritten by those installed in
-the second pass.</para>
+<para>Compilation is now complete, and at this point we would normally run the
+test suite. But, as mentioned before, the test suite framework is not in place
+yet. And there would be little point in running the tests anyhow, since the
+programs from this first pass will soon be replaced.</para>
 
 <para>And install the package:</para>
 
 <screen><userinput>make install</userinput></screen>
 
-<para>As a finishing touch we'll create the <filename
-class="symlink">/tools/bin/cc</filename> symlink. Many programs and
-scripts run <command>cc</command> instead of <command>gcc</command>,
+<para>As a finishing touch we'll create a symlink. Many programs and scripts
+run <command>cc</command> instead of <command>gcc</command>,
 a thing meant to keep programs generic and therefore usable on all kinds of
 Unix systems. Not everybody has the GNU C compiler installed. Simply running
 <command>cc</command> leaves the system administrator free to decide what
diff --git a/chapter05/gcc-pass2.xml b/chapter05/gcc-pass2.xml
index 34bc6f63a..da119311c 100644
--- a/chapter05/gcc-pass2.xml
+++ b/chapter05/gcc-pass2.xml
@@ -13,33 +13,33 @@
 <sect2>
 <title>Re-installation of GCC</title>
 
-<para>The tools required to test GCC and Binutils are installed now (Tcl, Expect
-and DejaGnu). We can continue on rebuilding GCC and Binutils, link them against
-the new Glibc, and test them properly (if performing the test suites in this
-chapter). One thing to note, however, is that these test suites are highly
-dependent on properly functioning pseudo terminals (PTYs) which are provided by
-your host distribution. These days, PTYs are most commonly implemented via the
+<para>The tools required to test GCC and Binutils are installed now: Tcl,
+Expect and DejaGnu. Therefore we can now rebuild GCC and Binutils, linking
+them against the new Glibc, and test them properly (if running the test suites
+in this chapter). One thing to note, however, is that these test suites are
+highly dependent on properly functioning pseudo terminals (PTYs) which are
+provided by your host. These days, PTYs are most commonly implemented via the
 <emphasis>devpts</emphasis> file system. You can quickly check if your host
 system is set up correctly in this regard by performing a simple test:</para>
 
 <screen><userinput>expect -c "spawn ls"</userinput></screen>
 
-<para>If you receive the message:</para>
+<para>The response might be:</para>
 
 <blockquote><screen>The system has no more ptys.  Ask your system administrator to create more.</screen></blockquote>
 
-<para>Your host distribution is not set up for proper PTY operation. In this
-case there is no point in running the test suites for GCC and Binutils until
-you are able to resolve the issue. You can consult the LFS Wiki at
-<ulink url="&wiki-root;"/> for more information on how to get PTYs
+<para>If you receive the above message, your host doesn't have its PTYs set up
+properly. In this case there is no point in running the test suites for GCC
+and Binutils until you are able to resolve the issue. You can consult the LFS
+Wiki at <ulink url="&wiki-root;"/> for more information on how to get PTYs
 working.</para>
 
 <para>This time we will build both the C and the C++ compilers, so you'll have
-to unpack all three GCC tarballs (-core, -g++, and -testsuite) in one and the
-same working directory. They will all unfold into a single
-<filename>&gcc-dir;/</filename> subdirectory.</para>
+to unpack both the core and the g++ tarballs (and testsuite too, if you want to
+run the tests). Unpacking them in your working directory, they will all unfold
+into a single <filename>&gcc-dir;/</filename> subdirectory.</para>
 
-<para>First correct one problem and make an essential adjustment:</para>
+<para>First correct a problem and make an essential adjustment:</para>
 
 <screen><userinput>patch -Np1 -i ../&gcc-nofixincludes-patch;
 patch -Np1 -i ../&gcc-specs-patch;</userinput></screen>
@@ -56,7 +56,7 @@ directory, resulting in GCC finding the fixed headers from the host system,
 which would most likely not match the Glibc version actually used for the LFS
 system.</para>
 
-<para>The last patch changes GCC's default location of the dynamic linker
+<para>The second patch changes GCC's default location of the dynamic linker
 (typically <filename>ld-linux.so.2</filename>). It also removes
 <filename class="directory">/usr/include</filename> from GCC's include search
 path. Patching now rather than adjusting the specs file after installation
@@ -86,6 +86,14 @@ variables that override the default optimization flags.</para>
 <para>The meaning of the new configure options:</para>
 
 <itemizedlist>
+<listitem><para><userinput>--enable-clocale=gnu</userinput>: This option
+ensures the correct locale model is selected for the C++ libraries under all
+circumstances. If the configure script finds the <emphasis>de_DE</emphasis>
+locale installed, it will select the correct <emphasis>gnu</emphasis> locale
+model. However, people who don't install the <emphasis>de_DE</emphasis> locale
+would run the risk of building ABI incompatible C++ libraries due to the wrong
+<emphasis>generic</emphasis> locale model being selected.</para></listitem>
+
 <listitem><para><userinput>--enable-threads=posix</userinput>: This enables
 C++ exception handling for multi-threaded code.</para></listitem>
 
@@ -96,16 +104,8 @@ handling of destructors. It also affects the C++ ABI and therefore results in
 C++ shared libraries and C++ programs that are interoperable with other Linux
 distributions.</para></listitem>
 
-<listitem><para><userinput>--enable-clocale=gnu</userinput>: This option ensures
-the correct locale model is selected for the C++ libraries under all
-circumstances. If the configure script finds the <emphasis>de_DE</emphasis>
-locale installed, it will select the correct model of <emphasis>gnu</emphasis>.
-However, people who don't install the <emphasis>de_DE</emphasis> locale, run the
-risk of building ABI incompatible C++ libraries due to the wrong locale model of
-<emphasis>generic</emphasis> being selected.</para></listitem>
-
-<listitem><para><userinput>--enable-languages=c,c++</userinput>: This option is
-needed to ensure that both C and C++ compilers are built.</para></listitem>
+<listitem><para><userinput>--enable-languages=c,c++</userinput>: This option
+ensures that both the C and C++ compilers are built.</para></listitem>
 </itemizedlist>
 
 <para>Compile the package:</para>
@@ -116,7 +116,7 @@ needed to ensure that both C and C++ compilers are built.</para></listitem>
 as the compiler we're using to compile this GCC was built from the exact same
 version of the GCC sources we used earlier.</para>
 
-<para>Compilation is now complete. As discussed earlier, we don't recommend
+<para>Compilation is now complete. As mentioned earlier, we don't recommend
 running the test suites for the temporary tools here in this chapter. If you
 still want to run the GCC test suite anyway, the following command will do
 so:</para>
@@ -150,17 +150,18 @@ supported by GCC have support for "__cxa_atexit" in their C libraries, so this
 test is not always expected to pass.</para>
 
 <para>The 24 unexpected passes for libstdc++ are due to the use of
-<emphasis>--enable-clocale=gnu</emphasis>, which is the correct choice on
-Glibc-based systems of versions 2.2.5 and above. The underlying locale support
-in the GNU C library is superior to that of the otherwise selected "generic"
-model (which may be applicable if for instance you were using Newlibc, Sun-libc
-or whatever libc). The libstdc++ test suite is apparently expecting the
-"generic" model, hence those tests are not always expected to pass.</para>
-
-<para>Unexpected failures often cannot be avoided. The GCC developers are
-usually aware of them but haven't yet gotten around to fixing them. In short,
-unless your results are vastly different from those at the above URL, it is safe
-to continue on.</para>
+<emphasis>--enable-clocale=gnu</emphasis>. This option, which is the correct
+choice on Glibc-based systems of versions 2.2.5 and above, enables in the GNU C
+library a locale support that is superior to the otherwise selected
+<emphasis>generic</emphasis> model (which may be applicable if for instance you
+were using Newlibc, Sun-libc or whatever other libc). The libstdc++ test suite
+is apparently expecting the <emphasis>generic</emphasis> model, hence those
+tests are not always expected to pass.</para>
+
+<para>Having a few unexpected failures often cannot be avoided. The GCC
+developers are usually aware of these, but haven't yet gotten around to fixing
+them. In short, unless your results are vastly different from those at the
+above URL, it is safe to continue.</para>
 
 <para>And finally install the package:</para>
 
@@ -168,9 +169,9 @@ to continue on.</para>
 
 <note><para>At this point it is strongly recommended to repeat the sanity check
 we performed earlier in this chapter. Refer back to
-<xref linkend="ch-tools-adjusting"/> and repeat the check. If the results are
-wrong, then most likely you forgot to apply the above mentioned GCC Specs
-patch.</para></note>
+<xref linkend="ch-tools-adjusting"/> and repeat the little test compilation. If
+the result is wrong, then most likely you forgot to apply the above mentioned
+GCC Specs patch.</para></note>
 
 </sect2>
 
diff --git a/chapter05/glibc.xml b/chapter05/glibc.xml
index 4e8ab7b66..9eda176a6 100644
--- a/chapter05/glibc.xml
+++ b/chapter05/glibc.xml
@@ -13,11 +13,11 @@
 <sect2>
 <title>Installation of Glibc</title>
 
-<para>This package is known to behave badly when you have changed its
-default optimization flags (including the -march and -mcpu options).
-Therefore, if you have defined any environment variables that override
-default optimizations, such as CFLAGS and CXXFLAGS, we recommend unsetting
-them when building Glibc.</para>
+<para>This package is known to behave badly when you change its default
+optimization flags (including the <emphasis>-march</emphasis> and
+<emphasis>-mcpu</emphasis> options). Therefore, if you have defined any
+environment variables that override default optimizations, such as CFLAGS and
+CXXFLAGS, we recommend unsetting them when building Glibc.</para>
 
 <para>Basically, compiling Glibc in any other way than the book suggests
 is putting the stability of your system at risk.</para>
@@ -40,7 +40,7 @@ cd ../glibc-build</userinput></screen>
 <itemizedlist>
 <listitem><para><userinput>--disable-profile</userinput>: This disables the
 building of the libraries with profiling information. Omit this option if you
-plan to do profiling.</para></listitem>
+plan to do profiling on the temporary tools.</para></listitem>
 
 <listitem><para><userinput>--enable-add-ons=linuxthreads</userinput>: This
 tells Glibc to use the Linuxthreads add-on as its threading
@@ -71,7 +71,7 @@ suppresses an annoying but harmless warning about a missing
 *** some features will be disabled.
 *** Check the INSTALL file for required versions.</screen></blockquote>
 
-<para>The missing or incompatible <filename>msgfmt</filename> program is
+<para>The missing or incompatible <command>msgfmt</command> program is
 generally harmless, but it's believed it can sometimes cause problems when
 running the test suite.</para>
 
@@ -79,7 +79,7 @@ running the test suite.</para>
 
 <screen><userinput>make</userinput></screen>
 
-<para>Compilation is now complete. As discussed earlier, we don't recommend
+<para>Compilation is now complete. As mentioned earlier, we don't recommend
 running the test suites for the temporary system here in this chapter. If you
 still want to run the Glibc test suite anyway, the following command will do
 so:</para>
@@ -90,10 +90,10 @@ so:</para>
 system, in particular the kernel. Additionally, here in this chapter some tests
 can be adversely affected by existing tools or environmental issues on the host
 system. Of course, these won't be a problem when we run the Glibc test suite
-inside the chroot environment of <xref linkend="chapter-building-system"/>. In general, the
-Glibc test suite is always expected to pass. However, as mentioned above, some
-failures are unavoidable in certain circumstances. Here is a list of the most
-common issues we are aware of:</para>
+inside the chroot environment of <xref linkend="chapter-building-system"/>. In
+general, the Glibc test suite is always expected to pass. However, as mentioned
+above, in certain circumstances some failures are unavoidable. Here is a list
+of the most common issues we are aware of:</para>
 
 <itemizedlist>
 <listitem><para>The <emphasis>math</emphasis> tests sometimes fail when running
@@ -117,20 +117,19 @@ fail due to test timeouts being exceeded.</para></listitem>
 </itemizedlist>
 
 <para>In summary, don't worry too much if you see Glibc test suite failures
-here in this chapter. The Glibc in <xref linkend="chapter-building-system"/> is the one we'll
-ultimately end up using so that is the one we would really like to see pass.
-But please keep in mind, even in <xref linkend="chapter-building-system"/> some failures
-could still occur -- the <emphasis>math</emphasis>
-tests for example. When experiencing a failure, make a note of it, then
-continue by reissuing the <command>make check</command>. The test suite
-should pick up where it left off and continue on. You can circumvent this
-stop-start sequence by issuing a <command>make -k check</command>. But if
-you do that, be sure to log the output so that you can later peruse the log
-file and examine the total number of failures.</para>
-
-<para>Though it is a harmless message, the install stage of Glibc will
-complain about the absence of <filename>/tools/etc/ld.so.conf</filename>.
-Fix this annoying little warning with:</para>
+here in this chapter. The Glibc in <xref linkend="chapter-building-system"/> is
+the one we'll ultimately end up using, so that is the one we would really like
+to see pass the tests (but even there some failures could still occur -- the
+<emphasis>math</emphasis> tests, for example). When experiencing a failure,
+make a note of it, then continue by reissuing the <command>make
+check</command>. The test suite should pick up where it left off and continue.
+You can circumvent this stop-start sequence by issuing a <command>make -k
+check</command>. But if you do that, be sure to log the output so that you can
+later peruse the log file and examine the total number of failures.</para>
+
+<para>Though it is a harmless message, the install stage of Glibc will at the
+end complain about the absence of <filename>/tools/etc/ld.so.conf</filename>.
+Prevent this confusing little warning with:</para>
 
 <screen><userinput>mkdir /tools/etc
 touch /tools/etc/ld.so.conf</userinput></screen>
diff --git a/chapter05/kernelheaders.xml b/chapter05/kernelheaders.xml
index ba3b2720a..48d4bfd1c 100644
--- a/chapter05/kernelheaders.xml
+++ b/chapter05/kernelheaders.xml
@@ -19,8 +19,8 @@ place where <command>gcc</command> can later find them.</para>
 <screen><userinput>make mrproper</userinput></screen>
 
 <para>This ensures that the kernel tree is absolutely clean. The kernel team
-recommends that this command be issued prior to <emphasis>each</emphasis> kernel
-compilation. You shouldn't rely on the source tree being clean after
+recommends that this command be issued prior to <emphasis>each</emphasis>
+kernel compilation. You shouldn't rely on the source tree being clean after
 untarring.</para>
 
 <para>Create the <filename>include/linux/version.h</filename> file:</para>
diff --git a/chapter05/tcl.xml b/chapter05/tcl.xml
index 4d51cb53c..e8b066b93 100644
--- a/chapter05/tcl.xml
+++ b/chapter05/tcl.xml
@@ -15,12 +15,12 @@
 <sect2>
 <title>Installation of Tcl</title>
 
-<para>This package and the next two are only installed to be able to run the 
-test suites for GCC and Binutils. Installing three packages just for testing 
-purposes may seem like overkill, but it is very reassuring, if not essential, 
+<para>This package and the next two are only installed to be able to run the
+test suites for GCC and Binutils. Installing three packages just for testing
+purposes may seem like overkill, but it is very reassuring, if not essential,
 to know that our most important tools are working properly. Even if you are
 not running the test suites here in this chapter as per our recommendation,
-these packages are still required for the test suites in the next
+these packages are still required for running the test suites in the next
 chapter.</para>
 
 <para>Prepare Tcl for compilation:</para>