Completed global edits for upcoming 6.0 release

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

36 files changed, 826 insertions, 727 deletions

diff --git a/chapter05/adjusting.xml b/chapter05/adjusting.xml
index f2a76ebe0..8994b9c02 100644
--- a/chapter05/adjusting.xml
+++ b/chapter05/adjusting.xml
@@ -8,31 +8,28 @@
 <?dbhtml filename="adjusting.html"?>
 
 <para>Now that the temporary C libraries have been installed, all
-the tools compiled in the rest of this chapter should be linked against these
-libraries. In order to accomplish this, the linker and the compiler's
-specs file, need to be adjsted.</para>
+tools compiled in the rest of this chapter should be linked against
+these libraries. In order to accomplish this, the linker and the
+compiler's specs file need to be adjusted.</para>
 
-<para> Some people would say that there is <emphasis><quote>black magic juju
-below this line</quote></emphasis>, but it is really very simple.</para>
-
-<para>First, the linker, adjusted at the end of the first pass of Binutils, is
-installed by running the following command from within
-the <filename class="directory">binutils-build</filename> directory:</para>
+<para>The linker, adjusted at the end of the first pass of Binutils,
+is installed by running the following command from within the
+<filename class="directory">binutils-build</filename> directory:</para>
 
 <screen><userinput>make -C ld install</userinput></screen>
 
-<para>From this point onwards everything will link <emphasis>only</emphasis>
+<para>From this point onwards, everything will link only
 against the libraries in <filename class="directory">/tools/lib</filename>.</para>
 
-<note><para>If you missed the earlier warning to retain the Binutils
-source and build directories from the first pass, dont worry - all is not lost.
-Just ignore the above command. This results in a small chance of the subsequent
-testing programs linking against libraries on the host. This is not ideal, but
-it's not a major problem. The situation is corrected when the second pass of
-Binutils is installed later on.</para></note>
+<note><para>If the earlier warning to retain the Binutils source and
+build directories from the first pass was missed, ignore the above
+command. This results in a small chance that the subsequent testing
+programs will link against libraries on the host. This is not ideal,
+but it is not a major problem. The situation is corrected when the
+second pass of Binutils is installed later.</para></note>
 
 <para>Now that the adjusted linker is installed, the Binutils build and source
-directories should be <emphasis>removed</emphasis>.</para>
+directories should be removed.</para>
 
 <para>The next task is to amend our GCC specs file so that it points
 to the new dynamic linker. A simple sed script will accomplish this:</para>
@@ -45,65 +42,70 @@ sed 's@ /lib/ld-linux.so.2@ /tools/lib/ld-linux.so.2@g' \
 mv -f tempspecfile $SPECFILE &amp;&amp;
 unset SPECFILE</userinput></screen>
 
-<para>It is recommended that the above command be cut-and-pasted in order to
-ensure correctness - Alternatively, the specs file can be edited by hand. This
-is done simply by replacing every occurrence of
-<quote>/lib/ld-linux.so.2</quote> with <quote>/tools/lib/ld-linux.so.2</quote>.
-</para>
-
-<para> Be sure to visually inspect the specs file in order to verify the intended changes have been made.</para>
-
-<important><para>If you are working on a platform where the name of the dynamic
-linker is something other than <filename>ld-linux.so.2</filename>, you
-<emphasis>must</emphasis> replace <filename>ld-linux.so.2</filename> with the
-name of your platform's dynamic linker in the above commands. Refer back to
-<xref linkend="ch-tools-toolchaintechnotes"/> if necessary.</para></important>
-
-<para>Lastly, there is a possibility that some include files from the host
-system have found their way into GCC's private include dir. This can happen
-as a result of of GCC's <quote>fixincludes</quote> process which runs as part
-of the GCC build.  We'll explain more about this further on in this chapter.
-Run the following commands to eliminate this possibility:</para>
+<para>It is recommended that the above command be cut-and-pasted in
+order to ensure correctness. Alternatively, the specs file can be
+edited by hand. This is done by replacing every occurrence of
+<quote>/lib/ld-linux.so.2</quote> with
+<quote>/tools/lib/ld-linux.so.2</quote>.</para>
+
+<para>Be sure to visually inspect the specs file in order to verify the
+intended changes have been made.</para>
+
+<important><para>If working on a platform where the name of the
+dynamic linker is something other than
+<filename>ld-linux.so.2</filename>, replace
+<filename>ld-linux.so.2</filename> with the name of the platform's
+dynamic linker in the above commands. Refer back to <xref
+linkend="ch-tools-toolchaintechnotes"/> if
+necessary.</para></important>
+
+<para>There is a possibility that some include files from the host
+system have found their way into GCC's private include dir. This can
+happen as a result of GCC's <quote>fixincludes</quote> process, which runs as part
+of the GCC build. This is explained in more detail later in this
+chapter. Run the following command to eliminate this
+possibility:</para>
 
 <screen><userinput>rm -f /tools/lib/gcc/*/*/include/{pthread.h,bits/sigthread.h}</userinput></screen>
 
-
-<caution><para>It is imperative at this point to stop and ensure that the basic
-functions (compiling and linking) of the new toolchain are working as expected.
-To perform a simple sanity check, run the following commands:</para>
+<caution><para>At this point, it is imperative to stop and ensure that
+the basic functions (compiling and linking) of the new toolchain are
+working as expected. To perform a sanity check, run the following
+commands:</para>
 
 <screen><userinput>echo 'main(){}' &gt; dummy.c
 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 of the form:</para>
+<para>If everything is working correctly, there should be no errors,
+and the output of the last command will be of the form:</para>
 
 <blockquote><screen><computeroutput>[Requesting program interpreter: /tools/lib/ld-linux.so.2]</computeroutput></screen></blockquote>
 
 <para>Note especially that <filename class="directory">/tools/lib</filename>
-appears as the prefix of our dynamic linker.</para>
-
-<para>If the output is not
-as shown above, or there was 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.
-First, perform the sanity check again, using <command>gcc</command> instead of
-<command>cc</command>. If this works, then the
-<filename class="symlink">/tools/bin/cc</filename> symlink is missing. Revisit
-<xref linkend="ch-tools-gcc-pass1"/> and install the symlink. Second, ensure your PATH
-is correct. You can check this by running <userinput>echo $PATH</userinput> and
-verifying that <filename class="directory">/tools/bin</filename> is at the head
-of the list. If the PATH is wrong it could mean you're not logged in as user
-<emphasis>lfs</emphasis> or something went wrong back in
-<xref linkend="ch-tools-settingenviron"/>. Third, something may have gone wrong with
-the specs file amendment above. In this case redo the specs file amendment
-being careful to cut-and-paste the commands.</para>
-
-<para>Once you are satisfied that all is well, clean up the test files:</para>
+appears as the prefix of the dynamic linker.</para>
+
+<para>If the output is not shown as above or there was no output at
+all, then something is wrong. Investigate and retrace the steps to
+find out where the problem is and correct it. This issue must be
+resolved before continuing on. First, perform the sanity check again,
+using <command>gcc</command> instead of <command>cc</command>. If this
+works, then the <filename>/tools/bin/cc</filename> symlink is missing.
+Revisit <xref linkend="ch-tools-gcc-pass1"/> and install the symlink.
+Next, ensure that the PATH is correct. This can be checked by running
+<command>echo $PATH</command> and verifying that <filename
+class="directory">/tools/bin</filename> is at the head of the list. If
+the PATH is wrong it could mean that you are not logged in as user
+<emphasis>lfs</emphasis> or that something went wrong back in <xref
+linkend="ch-tools-settingenviron"/> Another option is that something
+may have gone wrong with the specs file amendment above. In this case,
+redo the specs file amendment, being careful to cut-and-paste the
+commands.</para>
+
+<para>Once all is well, clean up the test files:</para>
 
 <screen><userinput>rm dummy.c a.out</userinput></screen>
 </caution>
 
-
 </sect1>
+
diff --git a/chapter05/bash.xml b/chapter05/bash.xml
index 18a399aee..c7f4193ac 100644
--- a/chapter05/bash.xml
+++ b/chapter05/bash.xml
@@ -35,15 +35,15 @@
 
 <screen><userinput>make</userinput></screen>
 
-<para>(If you want to test the results, then issue:
-<userinput>make tests</userinput>.)</para>
+<para>To test the results, issue: <userinput>make
+tests</userinput>.</para>
 
-<para>Then install it and its documentation:</para>
+<para>Install the package:</para>
 
 <screen><userinput>make install</userinput></screen>
 
-<para>And make a link for the programs that use <command>sh</command>
-for a shell:</para>
+<para>Make a link for the programs that use <command>sh</command> for
+a shell:</para>
 
 <screen><userinput>ln -s bash /tools/bin/sh</userinput></screen>
 
@@ -54,3 +54,4 @@ for a shell:</para>
 </sect2>
 
 </sect1>
+
diff --git a/chapter05/binutils-pass1.xml b/chapter05/binutils-pass1.xml
index 96ebbdfa6..3d953428b 100644
--- a/chapter05/binutils-pass1.xml
+++ b/chapter05/binutils-pass1.xml
@@ -31,11 +31,13 @@
 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 change its default
+<para>This package is known to have issues when its default
 optimization flags (including the <parameter>-march</parameter> and
-<parameter>-mcpu</parameter> options). Therefore, if you have defined any
-environment variables that override default optimizations, such as CFLAGS and
-CXXFLAGS, we recommend un-setting them when building Binutils.</para>
+<parameter>-mcpu</parameter> options) are changed. Therefore, if any
+environment variables that override default optimizations have been
+defined, such as <emphasis>CFLAGS</emphasis> and
+<emphasis>CXXFLAGS</emphasis>, we recommend un-setting them when
+building Binutils.</para>
 
 <para>The Binutils documentation recommends building Binutils outside of the
 source directory in a dedicated build directory:</para>
@@ -43,12 +45,12 @@ source directory in a dedicated build directory:</para>
 <screen><userinput>mkdir ../binutils-build
 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 --
-from the configuration up to 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>
+<note><para>In order for the SBU values listed in the rest of the book
+to be of any use, measure the time it takes to build this package from
+the configuration, up to and including the first install. To achieve
+this easily, 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>
 
@@ -65,9 +67,9 @@ programs in the <filename class="directory">/tools</filename> directory.</para><
 
 <varlistentry>
 <term><parameter>--disable-nls</parameter></term>
-<listitem><para>This disables internationalization (a word often shortened to 
-i18n). We don't need this for our static programs and <emphasis>nls</emphasis>
-often causes problems when linking statically.</para></listitem>
+<listitem><para>This disables internationalization. This is not needed
+for the static programs, and nls can cause problems when linking
+statically.</para></listitem>
 </varlistentry>
 </variablelist>
 
@@ -81,31 +83,33 @@ make LDFLAGS="-all-static"</userinput></screen>
 <variablelist>
 <varlistentry>
 <term><parameter>configure-host</parameter></term>
-<listitem><para>This forces all the subdirectories to be configured immediately. 
-A statically linked build will fail without it. We therefore use this option to work 
-around the problem.</para></listitem>
+<listitem><para>This forces all subdirectories to be configured
+immediately. A statically-linked build will fail without it. Use this
+option to work around the problem:</para></listitem>
 </varlistentry>
 
 <varlistentry>
 <term><parameter>LDFLAGS="-all-static"</parameter></term>
-<listitem><para>This tells the linker that all the Binutils programs should be 
-linked statically. However, strictly speaking, <parameter>"-all-static"</parameter>
-is passed to the <command>libtool</command> program, which then passes
+<listitem><para>This tells the linker that all Binutils programs
+should be linked statically. However, strictly speaking,
+<parameter>"-all-static"</parameter> is passed to the
+<command>libtool</command> program, which then passes
 <parameter>"-static"</parameter> to the linker.</para></listitem>
 </varlistentry>
 </variablelist>
 
-<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>Compilation is now complete. Ordinarily 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. The benefits of running the
+tests at this point would be minimal since the programs from this
+first pass will soon be replaced by those from the second.</para>
 
-<para>Now install the package:</para>
+<para>Install the package:</para>
 
 <screen><userinput>make install</userinput></screen>
 
-<para>Now prepare the linker for the <quote>Adjusting</quote> phase later on:</para>
+<para>Next, prepare the linker for the <quote>Adjusting</quote> phase
+later on:</para>
 
 <screen><userinput>make -C ld clean
 make -C ld LDFLAGS="-all-static" LIB_PATH=/tools/lib</userinput></screen>
@@ -115,8 +119,9 @@ make -C ld LDFLAGS="-all-static" LIB_PATH=/tools/lib</userinput></screen>
 <variablelist>
 <varlistentry>
 <term><parameter>-C ld clean</parameter></term>
-<listitem><para>This tells the make program to remove all the compiled files 
-in the <filename class="directory">ld</filename> subdirectory.</para></listitem>
+<listitem><para>This tells the make program to remove all compiled
+files in the <filename class="directory">ld</filename>
+subdirectory.</para></listitem>
 </varlistentry>
 
 <varlistentry>
@@ -124,18 +129,16 @@ in the <filename class="directory">ld</filename> subdirectory.</para></listitem>
 LIB_PATH=/tools/lib</parameter></term>
 <listitem><para>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>
+Makefile variable on the command line allows us to override the default value
+and point it to our temporary tools location. The value of this variable
+specifies the linker's default library search path. This preparation
+is used later in the chapter.</para></listitem>
 </varlistentry>
 </variablelist>
 
-
-<warning><para><emphasis>Do not yet remove</emphasis> the Binutils build and
-source directories. You will need them again in their current state a bit
-further on in this chapter.</para></warning>
-
+<warning><para><emphasis>Do not yet</emphasis> remove the Binutils
+build and source directories. These will be needed again in their
+current state later in this chapter.</para></warning>
 
 </sect2>
 
@@ -144,3 +147,4 @@ further on in this chapter.</para></warning>
 </sect2>
 
 </sect1>
+
diff --git a/chapter05/binutils-pass2.xml b/chapter05/binutils-pass2.xml
index b09b9fae6..0ae192f76 100644
--- a/chapter05/binutils-pass2.xml
+++ b/chapter05/binutils-pass2.xml
@@ -39,45 +39,30 @@ cd ../binutils-build</userinput></screen>
 <variablelist>
 <varlistentry>
 <term><parameter>--with-lib-path=/tools/lib</parameter></term>
-<listitem><para>This tells the configure script to specify the library search path 
-during the compilation of Binutils, resulting in <parameter>/tools/lib</parameter>
-to be passed to the linker. This prevents the linker from searching through library 
-directories on the host.</para></listitem>
+<listitem><para>This tells the configure script to specify the library
+search path during the compilation of Binutils, resulting in <filename
+class="directory">/tools/lib</filename> being passed to the linker.
+This prevents the linker from searching through library directories on
+the host.</para></listitem>
 </varlistentry>
 </variablelist>
 
-<para>Before starting to build Binutils, remember to unset any environment
-variables that override the default optimization flags.</para>
+<para>Before starting to build Binutils, remember to unset any
+environment variables that override the default optimization
+flags.</para>
 
 <para>Compile the package:</para>
 
 <screen><userinput>make</userinput></screen>
 
-<para>Compilation is now complete. As discussed earlier, running the test suite
-isn't mandatory for the temporary tools here in this chapter. If you do want to
-run the Binutils test suite though, the following command will do so:</para>
+<para>Compilation is now complete. As discussed earlier, running the
+test suite is not mandatory for the temporary tools here in this
+chapter. To run the Binutils test suite anyway, issue the following
+command:</para>
 
-<screen><userinput>make -k check</userinput></screen>
+<screen><userinput>make check</userinput></screen>
 
-<para>Except for a few known failures, the binutils tests should all pass. The
-exceptions to this rule are as follows:</para>
-
-<screen><computeroutput>* 5 FAIL (unexpected failure) for visibility
-* 1 FAIL for selective4
-* 1 FAIL for selective5</computeroutput></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 GCC package. However, if a failure occurs here, it should be easy
-to spot. The output shown will contain something like:</para>
-
-<blockquote><screen><computeroutput>make[1]: *** [check-binutils] Error 2</computeroutput></screen></blockquote>
-
--->
-
-<para>And install the package:</para>
+<para>Install the package:</para>
 
 <screen><userinput>make install</userinput></screen>
 
@@ -88,10 +73,9 @@ chapter:</para>
 make -C ld LIB_PATH=/usr/lib:/lib</userinput></screen>
 
 
-<warning><para><emphasis>Do not yet remove</emphasis> the Binutils source and
-build directories. You will need these directories again in the next chapter
-in the state they are in now.</para></warning>
-
+<warning><para><emphasis>Do not</emphasis> yet remove the Binutils source and
+build directories. hese directories will be needed again in the next
+chapter in their current state.</para></warning>
 
 </sect2>
 
@@ -100,3 +84,4 @@ in the state they are in now.</para></warning>
 </sect2>
 
 </sect1>
+
diff --git a/chapter05/bison.xml b/chapter05/bison.xml
index 3be3c4020..d0b30405f 100644
--- a/chapter05/bison.xml
+++ b/chapter05/bison.xml
@@ -35,10 +35,10 @@
 
 <screen><userinput>make</userinput></screen>
 
-<para>To test the results, issue:
-<userinput>make check</userinput>.</para>
+<para>To test the results, issue: <userinput>make
+check</userinput>.</para>
 
-<para>Now install the package:</para>
+<para>Install the package:</para>
 
 <screen><userinput>make install</userinput></screen>
 
@@ -49,3 +49,4 @@
 </sect2>
 
 </sect1>
+
diff --git a/chapter05/bzip2.xml b/chapter05/bzip2.xml
index ece8fc2bf..952b46df4 100644
--- a/chapter05/bzip2.xml
+++ b/chapter05/bzip2.xml
@@ -28,11 +28,11 @@
 <title>Installation of Bzip2</title>
 
 <para>The Bzip2 package doesn't contain a <command>configure</command>
-script. Compile it with a straightforward:</para>
+script. Compile it with:</para>
 
 <screen><userinput>make</userinput></screen>
 
-<para>And install it:</para>
+<para>Install the package:</para>
 
 <screen><userinput>make PREFIX=/tools install</userinput></screen>
 
@@ -43,3 +43,4 @@ script. Compile it with a straightforward:</para>
 </sect2>
 
 </sect1>
+
diff --git a/chapter05/coreutils.xml b/chapter05/coreutils.xml
index 27eea305f..39eac192b 100644
--- a/chapter05/coreutils.xml
+++ b/chapter05/coreutils.xml
@@ -31,32 +31,35 @@
 
 <screen><userinput>DEFAULT_POSIX2_VERSION=199209 ./configure --prefix=/tools</userinput></screen>
 
-<para>This package has an issue when compiled against versions of Glibc
-later than 2.3.2.  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.  Backwards compatibility is achieved by setting the
-DEFAULT_POSIX2_VERSION environment variable to <quote>199209</quote> in the above
-command.  If you don't want coreutils to be backwards compatible
-with the traditional syntax, then simply omit setting the DEFAULT_POSIX2_VERSION
-environment variable.  Realise though, that doing so will mean you'll have
-to deal with the consequences yourself: patch the many packages that still use
-the old syntax.  We therefore recommend using the instructions exactly as given
-above.</para>
+<para>This package has an issue when compiled against versions of
+Glibc later than 2.3.2. 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. Backwards
+compatibility is achieved by setting the
+<emphasis>DEFAULT_POSIX2_VERSION</emphasis> environment variable to
+<quote>199209</quote> in the above command. If you do not want
+coreutils to be backwards compatible with the traditional syntax, then
+omit setting the <emphasis>DEFAULT_POSIX2_VERSION</emphasis>
+environment variable. It is important to remember that doing so will
+have consequences, including the need to patch the many packages that
+still use the old syntax. We therefore recommend using the
+instructions exactly as given above.</para>
 
 <para>Compile the package:</para>
 
 <screen><userinput>make</userinput></screen>
 
-<para>(If you want to test the results, then issue:
-<userinput>make RUN_EXPENSIVE_TESTS=yes check</userinput>. The
-<parameter>RUN_EXPENSIVE_TESTS=yes</parameter> parameter tells the test suite to
-run several additional tests that are considered relatively expensive on some
-platforms but generally are not a problem on Linux.)</para>
+<para>To test the results, issue: <userinput>make
+RUN_EXPENSIVE_TESTS=yes check</userinput>.  The
+<parameter>RUN_EXPENSIVE_TESTS=yes</parameter> parameter tells the
+test suite to run several additional tests that are considered
+relatively expensive (in terms of CPU power and memory usage) on some
+platforms, but generally are not a problem on Linux.</para>
 
-<para>And install the package:</para>
+<para>Install the package:</para>
 
 <screen><userinput>make install</userinput></screen>
 
@@ -67,3 +70,4 @@ platforms but generally are not a problem on Linux.)</para>
 </sect2>
 
 </sect1>
+
diff --git a/chapter05/dejagnu.xml b/chapter05/dejagnu.xml
index f9de3faf0..6a94c22d3 100644
--- a/chapter05/dejagnu.xml
+++ b/chapter05/dejagnu.xml
@@ -52,7 +52,7 @@ GCC, Glibc, Grep, Make, Sed</seg></seglistitem>
 <term><command>runtest</command></term>
 <listitem>
 <indexterm zone="ch-tools-dejagnu runtest"><primary sortas="b-runtest">runtest</primary></indexterm>
-<para>is the wrapper script that finds the proper
+<para>a wrapper script that locates the proper
 <command>expect</command> shell and then runs DejaGNU.</para>
 </listitem>
 </varlistentry>
@@ -60,5 +60,5 @@ GCC, Glibc, Grep, Make, Sed</seg></seglistitem>
 
 </sect2>
 
-
 </sect1>
+
diff --git a/chapter05/diffutils.xml b/chapter05/diffutils.xml
index 3fc78f0ee..7f8d9be2d 100644
--- a/chapter05/diffutils.xml
+++ b/chapter05/diffutils.xml
@@ -35,7 +35,7 @@
 
 <screen><userinput>make</userinput></screen>
 
-<para>And install it:</para>
+<para>Install the package:</para>
 
 <screen><userinput>make install</userinput></screen>
 
@@ -46,3 +46,4 @@
 </sect2>
 
 </sect1>
+
diff --git a/chapter05/expect.xml b/chapter05/expect.xml
index 2e68a3aba..64e52cc98 100644
--- a/chapter05/expect.xml
+++ b/chapter05/expect.xml
@@ -29,7 +29,7 @@ GCC, Glibc, Grep, Make, Sed, Tcl</seg></seglistitem>
 <sect2 role="installation">
 <title>Installation of Expect</title>
 
-<para>First fix a bug that can result in bogus failures during the GCC test
+<para>First fix a bug that can result in false failures during the GCC test
 suite run:</para>
 
 <screen><userinput>patch -Np1 -i ../expect-&expect-version;-spawn-1.patch</userinput></screen>
@@ -43,17 +43,16 @@ suite run:</para>
 <variablelist>
 <varlistentry>
 <term><parameter>--with-tcl=/tools/lib</parameter></term>
-<listitem><para>This ensures that
-the configure script finds the Tcl installation in our temporary tools location.
-We don't want it to find an existing one that may possibly reside on the host
-system.</para></listitem>
+<listitem><para>This ensures that the configure script finds the Tcl installation in
+the temporary tools location instead of possibly finding an existing
+one on the host system.</para></listitem>
 </varlistentry>
 
 <varlistentry>
 <term><parameter>--with-x=no</parameter></term>
-<listitem><para>This tells the configure
-script not to search for Tk (the Tcl GUI component) or the X Window System
-libraries, both of which may possibly reside on the host system.</para></listitem>
+<listitem><para>This tells the configure script not to search for Tk
+(the Tcl GUI component) or the X Window System libraries, both of
+which may possibly reside on the host system.</para></listitem>
 </varlistentry>
 </variablelist>
 
@@ -61,13 +60,13 @@ libraries, both of which may possibly reside on the host system.</para></listite
 
 <screen><userinput>make</userinput></screen>
 
-<para>(If you want to test the results, then issue:
-<userinput>make test</userinput>. However, the Expect test suite is known to
-experience failures under certain host conditions that are not within our
-control. Therefore, test suite failures here are not surprising, and are not
-considered critical.)</para>
+<para>To test the results, issue: <userinput>make test</userinput>.
+Note that the Expect test suite is known to experience failures under
+certain host conditions that are not within our control. Therefore,
+test suite failures here are not surprising, and are not considered
+critical.</para>
 
-<para>And install it:</para>
+<para>Install the package:</para>
 
 <screen><userinput>make SCRIPTS="" install</userinput></screen>
 
@@ -76,8 +75,8 @@ considered critical.)</para>
 <variablelist>
 <varlistentry>
 <term><parameter>SCRIPTS=""</parameter></term>
-<listitem><para>This prevents installation
-of the supplementary expect scripts which are not needed.</para></listitem>
+<listitem><para>This prevents installation of the supplementary expect
+scripts, which are not needed.</para></listitem>
 </varlistentry>
 </variablelist>
 
@@ -85,7 +84,6 @@ of the supplementary expect scripts which are not needed.</para></listitem>
 
 </sect2>
 
-
 <sect2 id="contents-expect" role="content"><title>Contents of Expect</title>
 
 <segmentedlist>
diff --git a/chapter05/findutils.xml b/chapter05/findutils.xml
index aa204ccf5..10015b45b 100644
--- a/chapter05/findutils.xml
+++ b/chapter05/findutils.xml
@@ -35,10 +35,10 @@
 
 <screen><userinput>make</userinput></screen>
 
-<para>(If you want to test the results, then issue:
-<userinput>make check</userinput>.)</para>
+<para>To test the results, issue: <userinput>make
+check</userinput>.</para>
 
-<para>And install the package:</para>
+<para>Install the package:</para>
 
 <screen><userinput>make install</userinput></screen>
 
@@ -49,3 +49,4 @@
 </sect2>
 
 </sect1>
+
diff --git a/chapter05/flex.xml b/chapter05/flex.xml
index b1c6b3525..139c8bd85 100644
--- a/chapter05/flex.xml
+++ b/chapter05/flex.xml
@@ -27,14 +27,15 @@
 <sect2 role="installation">
 <title>Installation of Flex</title>
 
-<para>Flex contains several known bugs. Fix these with the following patch:</para>
+<para>Flex contains several known bugs. These can be fixed with the
+following patch:</para>
 
 <screen><userinput>patch -Np1 -i ../flex-&flex-version;-debian_fixes-2.patch</userinput></screen>
 
-<para>The GNU autotools detects that the Flex source code has been modified by
-the previous patch, and tries to update the manual page accordingly, but this
-breaks on many systems, and the default page is fine, so make sure it doesn't
-get regenerated:</para>
+<para>The GNU autotools will detect that the Flex source code has been
+modified by the previous patch and tries to update the manual page
+accordingly.  This does not work on many systems, and the default page is
+fine, so make sure it does not get regenerated:</para>
 
 <screen><userinput>touch doc/flex.1</userinput></screen>
 
@@ -49,7 +50,7 @@ get regenerated:</para>
 <para>To test the results, issue:
 <userinput>make check</userinput>.</para>
 
-<para>Now install the package:</para>
+<para>Install the package:</para>
 
 <screen><userinput>make install</userinput></screen>
 
@@ -60,3 +61,4 @@ get regenerated:</para>
 </sect2>
 
 </sect1>
+
diff --git a/chapter05/gawk.xml b/chapter05/gawk.xml
index 356cf2339..e9b5ab634 100644
--- a/chapter05/gawk.xml
+++ b/chapter05/gawk.xml
@@ -35,10 +35,10 @@
 
 <screen><userinput>make</userinput></screen>
 
-<para>(If you want to test the results, then issue:
-<userinput>make check</userinput>.)</para>
+<para>To test the results (not necessary), issue: <userinput>make
+check</userinput>.</para>
 
-<para>And install it:</para>
+<para>Install the package:</para>
 
 <screen><userinput>make install</userinput></screen>
 
@@ -49,3 +49,4 @@
 </sect2>
 
 </sect1>
+
diff --git a/chapter05/gcc-pass1.xml b/chapter05/gcc-pass1.xml
index 3f43d67bf..47876148e 100644
--- a/chapter05/gcc-pass1.xml
+++ b/chapter05/gcc-pass1.xml
@@ -27,17 +27,19 @@
 <sect2 role="installation">
 <title>Installation of GCC</title>
 
-<para>Unpack only the GCC-core tarball, as we won't be needing the C++ compiler
-nor the test suite here.</para>
+<para>Unpack only the gcc-core tarball because neither the C++
+compiler nor the test suite will be needed here.</para>
 
-<para>This package is known to behave badly when you change its default
+<para>This package is known to have issues when the default
 optimization flags (including the <parameter>-march</parameter> and
-<parameter>-mcpu</parameter> options). Therefore, if you have defined any
-environment variables that override default optimizations, such as CFLAGS and
-CXXFLAGS, we recommend un-setting them when building GCC.</para>
+<parameter>-mcpu</parameter> options) are changed. Therefore, if any
+environment variables that override default optimizations have been
+defined, such as <emphasis>CFLAGS</emphasis> and
+<emphasis>CXXFLAGS</emphasis>, we recommend un-setting them when
+building GCC.</para>
 
-<para>The GCC documentation recommends building GCC outside of the source
-directory in a dedicated build directory:</para>
+<para>The GCC documentation recommends building GCC outside of the
+source directory in a dedicated build directory:</para>
 
 <screen><userinput>mkdir ../gcc-build
 cd ../gcc-build</userinput></screen>
@@ -55,27 +57,30 @@ cd ../gcc-build</userinput></screen>
 <term><parameter>--with-local-prefix=/tools</parameter></term>
 <listitem><para>The purpose of this switch is to remove <filename class="directory">/usr/local/include</filename>
 from <command>gcc</command>'s include search path. This is not absolutely
-essential; however, we want to try to minimize the influence of the host
-system, so this a sensible thing to do.</para></listitem>
+essential, however, this helps to minimize the influence of the host
+system.</para></listitem>
 </varlistentry>
 
 <varlistentry>
 <term><parameter>--enable-shared</parameter></term>
-<listitem><para>This switch may
-seem counter-intuitive at first. But using it allows the building of
-<filename>libgcc_s.so.1</filename> and <filename>libgcc_eh.a</filename>, and
-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 GCC binaries will still be linked
-statically, as this is controlled by the <parameter>-static</parameter>
-value of BOOT_LDFLAGS in the next step.</para></listitem>
+<listitem><para>This switch may seem counter-intuitive at first.
+However, this switch allows the building of
+<filename>libgcc_s.so.1</filename> and
+<filename>libgcc_eh.a</filename>, and 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 GCC binaries will still be linked statically,
+as this is controlled by the <parameter>-static</parameter> value of
+the <emphasis>BOOT_LDFLAGS</emphasis> variable in the next
+step.</para></listitem>
 </varlistentry>
 
 <varlistentry>
 <term><parameter>--enable-languages=c</parameter></term>
 <listitem><para>This option
-ensures that only the C compiler is built. The option is only needed when you
-have downloaded and unpacked the full GCC tarball.</para></listitem>
+ensures that only the C compiler is built. This option is only needed when you
+have downloaded and unpacked the full GCC tarball, as opposed to just
+having unpacked the gcc-core tarball.</para></listitem>
 </varlistentry>
 </variablelist>
 
@@ -93,30 +98,30 @@ have downloaded and unpacked the full GCC tarball.</para></listitem>
 
 <varlistentry>
 <term><parameter>bootstrap</parameter></term>
-<listitem><para>This target doesn't just
-compile GCC, but compiles it several times. It uses the programs compiled in
-a first round to compile itself a second time, and then again a third time.
-It then compares these second and third compiles to make sure it can
-reproduce itself flawlessly, which most probably means that it was
-compiled correctly.</para></listitem>
+<listitem><para>This target does not just compile GCC, but compiles it
+several times. It uses the programs compiled in a first round to
+compile itself a second time, and then again a third time. It then
+compares these second and third compiles to make sure it can reproduce
+itself flawlessly.  This also implies that it was compiled
+correctly.</para></listitem>
 </varlistentry>
 </variablelist>
 
-<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>Compilation is now complete. At this point, the test suite would
+normally be run, but, as mentioned before, the test suite framework is
+not in place yet. The benefits of running the tests at this point
+would be minimal since the programs from this first pass will soon be
+replaced.</para>
 
-<para>Now install the package:</para>
+<para>Install the package:</para>
 
 <screen><userinput>make install</userinput></screen>
 
-<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
-C compiler to install, as long as there's a symlink pointing to it:</para>
+<para>As a finishing touch, create a symlink. Many programs and
+scripts run <command>cc</command> instead of <command>gcc</command>, which is used to keep programs generic
+and therefore usable on all kinds of UNIX systems where the GNU C compiler
+is not always installed. Running <command>cc</command> leaves the system administrator
+free to decide what C compiler to install.</para>
 
 <screen><userinput>ln -s gcc /tools/bin/cc</userinput></screen>
 
@@ -127,3 +132,4 @@ C compiler to install, as long as there's a symlink pointing to it:</para>
 </sect2>
 
 </sect1>
+
diff --git a/chapter05/gcc-pass2.xml b/chapter05/gcc-pass2.xml
index 2967be121..053c94707 100644
--- a/chapter05/gcc-pass2.xml
+++ b/chapter05/gcc-pass2.xml
@@ -19,19 +19,22 @@
 <seglistitem><seg>11.0 SBU</seg><seg>274 MB</seg></seglistitem>
 </segmentedlist>
 
+<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="../chapter06/gcc.xml" xpointer="xpointer(/sect1/sect2[1]/segmentedlist[2])"/>
+
 </sect2>
 
 <sect2 role="installation">
 <title>Re-installation of GCC</title>
 
-<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
-<systemitem class="filesystem">devpts</systemitem> file system. You can quickly check if your host
-system is set up correctly in this regard by performing a simple test:</para>
+<para>The tools required to test GCC and Binutils -- Tcl, Expect and
+DejaGNU -- are installed now. GCC and Binutils can now be rebuilt,
+linking them against the new Glibc and testing them properly (if
+running the test suites in this chapter). Please note that these test
+suites are highly dependent on properly functioning pseudo terminals
+(PTYs) which are provided by the host. PTYs are most commonly
+implemented via the <systemitem class="filesystem">devpts</systemitem>
+file system. Check to see if the host system is set up correctly in
+this regard by performing a quick test:</para>
 
 <screen><userinput>expect -c "spawn ls"</userinput></screen>
 
@@ -39,44 +42,48 @@ system is set up correctly in this regard by performing a simple test:</para>
 
 <blockquote><screen><computeroutput>The system has no more ptys.  Ask your system administrator to create more.</computeroutput></screen></blockquote>
 
-<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>If the above message is received, the host does not have its
+PTYs set up properly. In this case, there is no point in running the
+test suites for GCC and Binutils until this issue is resolved. Please
+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 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 class="directory">gcc-&gcc-version;/</filename> subdirectory.</para>
+<para>Because the C and the C++ compilers will be built, unpack both
+the core and the g++ tarballs (as well as testsuite, if you want to
+run the tests). By unpacking them in the working directory, they will
+all unfold into a single <filename
+class="directory">gcc-&gcc-version;/</filename> subdirectory.</para>
 
-<para>First correct a problem and make an essential adjustment:</para>
+<para>First correct a known problem and make an essential adjustment:</para>
 
 <screen><userinput>patch -Np1 -i ../gcc-&gcc-version;-no_fixincludes-1.patch
 patch -Np1 -i ../gcc-&gcc-version;-specs-1.patch</userinput></screen>
 
-<para>The first patch disables the GCC <command>fixincludes</command> script. We
-mentioned this briefly earlier, but a slightly more in-depth explanation of
-the fixincludes process is warranted here. Under normal circumstances, the GCC
-<command>fixincludes</command> script scans your system for header files that need to be fixed. It
-might find that some Glibc header files on your host system need to be fixed,
-fix them and put them in the GCC private include directory. Then, later on in
-<xref linkend="chapter-building-system"/>, after we've installed the newer
-Glibc, this private include directory would be searched before the system
-include 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 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
-ensures that our new dynamic linker gets used during the actual build of GCC.
-That is, all the final (and temporary) binaries created during the build will
-link against the new Glibc.</para>
-
-<important><para>The above patches are <emphasis>critical</emphasis> in ensuring
-a successful overall build. Do not forget to apply them.</para></important>
+<para>The first patch disables the GCC <command>fixincludes</command>
+script. This was briefly mentioned earlier, but a more in-depth
+explanation of the fixincludes process is warranted here. Under normal
+circumstances, the GCC <command>fixincludes</command> script scans the
+system for header files that need to be fixed. It might find that some
+Glibc header files on the host system need to be fixed, and will fix
+them and put them in the GCC private include directory. In <xref
+linkend="chapter-building-system"/>, after the newer Glibc had been
+installed, this private include directory will be searched before the
+system include directory.  This may result in GCC finding the fixed
+headers from the host system, which most likely will not match the
+Glibc version used for the LFS system.</para>
+
+<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 ensures that the new dynamic linker is used during the
+actual build of GCC. That is, all of the final (and temporary)
+binaries created during the build will link against the new
+Glibc.</para>
+
+<important><para>The above patches are critical in ensuring a
+successful overall build. Do not forget to apply
+them.</para></important>
 
 <para>Create a separate build directory again:</para>
 
@@ -99,28 +106,30 @@ variables that override the default optimization flags.</para>
 <variablelist>
 <varlistentry>
 <term><parameter>--enable-clocale=gnu</parameter></term>
-<listitem><para>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>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 gnu locale model. However, if the <emphasis>de_DE</emphasis> locale is not
+installed, there is the risk of building Application Binary Interface
+(ABI)-incompatible C++ libraries because the incorrect generic locale
+model may be selected.</para></listitem>
 </varlistentry>
 
 <varlistentry>
 <term><parameter>--enable-threads=posix</parameter></term>
-<listitem><para>This enables
-C++ exception handling for multi-threaded code.</para></listitem>
+<listitem><para>This enables C++ exception handling for multi-threaded
+code.</para></listitem>
 </varlistentry>
 
 <varlistentry>
 <term><parameter>--enable-__cxa_atexit</parameter></term>
-<listitem><para>This option
-allows use of __cxa_atexit, rather than atexit, to register C++ destructors for
-local statics and global objects and is essential for fully standards-compliant
-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
+<listitem><para>This option allows use of
+<emphasis>__cxa_atexit</emphasis>, rather than
+<emphasis>atexit</emphasis>, to register C++ destructors for local
+statics and global objects.  This option is essential for fully
+standards-compliant 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>
 </varlistentry>
 
@@ -132,9 +141,9 @@ ensures that both the C and C++ compilers are built.</para></listitem>
 
 <varlistentry>
 <term><parameter>--disable-libstdcxx-pch</parameter></term>
-<listitem><para>Don't build the
-PCH (pre-compiled header) for libstdc++. It takes up a ton of space, and we
-have no use for it.</para></listitem>
+<listitem><para>Do not build the pre-compiled header (PCH) for
+libstdc++. It takes up a lot of space, and we have no use for
+it.</para></listitem>
 </varlistentry>
 </variablelist>
 
@@ -142,44 +151,48 @@ have no use for it.</para></listitem>
 
 <screen><userinput>make</userinput></screen>
 
-<para>There is no need to use the <parameter>bootstrap</parameter> target now,
-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>There is no need to use the <parameter>bootstrap</parameter>
+target now because the compiler being used to compile this GCC was
+built from the exact same version of the GCC sources used
+earlier.</para>
 
-<para>Compilation is now complete. As mentioned earlier, running the test suites
-for the temporary tools compiled in this chapter is not mandatory.  If you want to run the GCC test suite anyway, the following command will do so:</para>
+<para>Compilation is now complete. As previously mentioned, running
+the test suites for the temporary tools compiled in this chapter is
+not mandatory. To run the GCC test suite anyway, use the following
+command:</para>
 
 <screen><userinput>make -k check</userinput></screen>
 
 <para>The <parameter>-k</parameter> flag is used to make the test suite run
-through to completion and not stop at the first failure. The GCC test suite is
-very comprehensive and is almost guaranteed to generate a few failures. To get
-a summary of the test suite results, run this:</para>
+through to completion and not stop at the first failure. The GCC test
+suite is very comprehensive and is almost guaranteed to generate a few
+failures. To receive a summary of the test suite results, run:</para>
  
 <screen><userinput>../gcc-&gcc-version;/contrib/test_summary</userinput></screen>
 
-<para>(For just the summaries, pipe the output through
-<userinput>grep -A7 Summ</userinput>.)</para>
+<para>For only the summaries, pipe the output through
+<userinput>grep -A7 Summ</userinput>.</para>
 
-<para>You can compare your results to those posted to the gcc-testresults
-mailing list for similar configurations to your own. For an example of how
-current GCC-&gcc-version; should look on i686-pc-linux-gnu, see
-<ulink url="http://gcc.gnu.org/ml/gcc-testresults/2004-07/msg00179.html"/>.</para>
+<para>Results can be compared to those posted to the gcc-testresults
+mailing list to see similar configurations to the one being built. For
+an example of how current GCC-&gcc-version; should look on
+i686-pc-linux-gnu, see <ulink
+url="http://gcc.gnu.org/ml/gcc-testresults/2004-07/msg00179.html"/>.</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>Having a few unexpected failures often cannot be avoided. The
+GCC developers are usually aware of these issues, but have not
+resolved them yet. Unless the test results are vastly different from
+those at the above URL, it is safe to continue.</para>
 
-<para>And finally install the package:</para>
+<para>Install the package:</para>
 
 <screen><userinput>make install</userinput></screen>
 
-<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 little test compilation. If
-the result is wrong, then most likely you forgot to apply the above mentioned
-GCC Specs patch.</para></note>
+<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 test compilation.  If
+the result is wrong, the most likely reason is that the GCC Specs
+patch was not properly applied.</para></note>
 
 </sect2>
 
@@ -188,3 +201,4 @@ GCC Specs patch.</para></note>
 </sect2>
 
 </sect1>
+
diff --git a/chapter05/gettext.xml b/chapter05/gettext.xml
index d88a1a358..b77bc2284 100644
--- a/chapter05/gettext.xml
+++ b/chapter05/gettext.xml
@@ -37,18 +37,18 @@
 <variablelist>
 <varlistentry>
 <term><parameter>--disable-libasprintf</parameter></term>
-<listitem><para>This flag tells
-Gettext that we don't want its asprintf library.  Nothing in this chapter or the next
-requires this, and Gettext gets rebuilt later, so we exclude it to save
-time/space.</para></listitem>
+<listitem><para>This flag tells Gettext not to include its
+<filename>asprintf</filename> library. Because nothing in this chapter
+or the next requires this library and Gettext gets rebuilt later,
+exclude it to save time and space.</para></listitem>
 </varlistentry>
 
 <varlistentry>
 <term><parameter>--disable-csharp</parameter></term>
-<listitem><para>Gettext has a nasty
-habit of searching for a C# compiler on the host, and building bindings for it.
-We've already <quote>locked</quote> ourselves into the temporary tools though,
-which doesn't have a C# compiler.</para></listitem>
+<listitem><para>Gettext has an unwanted habit of searching for a C#
+compiler on the host, and building bindings for it. We have already
+<quote>locked</quote> ourselves into the temporary tools which does
+not include a C# compiler.</para></listitem>
 </varlistentry>
 </variablelist>
 
@@ -56,14 +56,14 @@ which doesn't have a C# compiler.</para></listitem>
 
 <screen><userinput>make</userinput></screen>
 
-<para>(If you want to test the results, then issue: <userinput>make
-check</userinput>. This takes a very long time, around 7 SBUs. Moreover, the
-Gettext test suite is known to experience failures under certain host
-conditions -- for example when it finds a Java compiler on the host (but an
-experimental patch to disable Java is available from the LFS Patches
-project).)</para>
+<para>To test the results, issue: <userinput>make check</userinput>.
+This takes quite some time, around 7 SBUs. The Gettext test suite is
+known to experience failures under certain host conditions, for
+example when it finds a Java compiler on the host.  An experimental
+patch to disable Java is available from the LFS Patches project at
+<ulink url="&patches-root;"/></para>
 
-<para>And install the package:</para>
+<para>Install the package:</para>
 
 <screen><userinput>make install</userinput></screen>
 
@@ -74,3 +74,4 @@ project).)</para>
 </sect2>
 
 </sect1>
+
diff --git a/chapter05/glibc.xml b/chapter05/glibc.xml
index de1458c2a..8d2489565 100644
--- a/chapter05/glibc.xml
+++ b/chapter05/glibc.xml
@@ -27,14 +27,17 @@
 <sect2 role="installation">
 <title>Installation of Glibc</title>
 
-<para>This package is known to behave badly when you change its default
+<para>This package is known to have issues when the default
 optimization flags (including the <parameter>-march</parameter> and
-<parameter>-mcpu</parameter> options). Therefore, if you have defined any
-environment variables that override default optimizations, such as CFLAGS and
-CXXFLAGS, we recommend un-setting them when building Glibc.</para>
+<parameter>-mcpu</parameter> options) are changed. Therefore, if any
+environment variables that override default optimizations have been
+defined, such as <emphasis>CFLAGS</emphasis> and
+<emphasis>CXXFLAGS</emphasis>, it is recommended that these be un-set
+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>
+<para>It should be noted that compiling Glibc in any way other than
+the method suggested in this book puts the stability of the system at
+risk.</para>
 
 <para>The Glibc documentation recommends building Glibc outside of the source
 directory in a dedicated build directory:</para>
@@ -54,9 +57,9 @@ cd ../glibc-build</userinput></screen>
 <variablelist>
 <varlistentry>
 <term><parameter>--disable-profile</parameter></term>
-<listitem><para>This builds the
-libraries without profiling information. Omit this option if you plan to do
-profiling on the temporary tools.</para></listitem>
+<listitem><para>This builds the libraries without profiling
+information. Omit this option if profiling on the temporary tools is
+necessary.</para></listitem>
 </varlistentry>
 
 <varlistentry>
@@ -67,51 +70,52 @@ library.</para></listitem>
 
 <varlistentry>
 <term><parameter>--with-tls</parameter></term>
-<listitem><para>This tells Glibc to include support for TLS (thread-local storage).
-This is required for NPTL to work. </para></listitem>
+<listitem><para>This tells Glibc to include support for Thread-Local
+Storage (TLS). This is required in order for NPTL to work.
+</para></listitem>
 </varlistentry>
 
 <varlistentry>
 <term><parameter>--with-__thread</parameter></term>
-<listitem><para>This tells Glibc to include thread support, this is for proper
-compiling of the thread-local storage.</para></listitem>
+<listitem><para>This tells Glibc to include thread support. This is
+required in order for TLS to be properly compiled.</para></listitem>
 </varlistentry>
 
 <varlistentry>
 <term><parameter>--enable-kernel=2.6.0</parameter></term>
-<listitem><para>This tells Glibc to compile the library for support of
-linux 2.6.x kernels.
-</para></listitem>
+<listitem><para>This tells Glibc to compile the library with support
+for 2.6.x Linux kernels.</para></listitem>
 </varlistentry>
 
 <varlistentry>
 <term><parameter>--with-binutils=/tools/bin</parameter></term>
-<listitem><para>Strictly speaking this switch is not required. But it does ensure 
-nothing can go wrong with regard to what Binutils programs get used during the 
+<listitem><para>While not required, this switch ensures that there are
+no errors pertaining to which Binutils programs get used during the
 Glibc build.</para></listitem>
 </varlistentry>
 
 <varlistentry>
 <term><parameter>--without-gd</parameter></term>
-<listitem><para>This prevents the build of the <command>memusagestat</command>
-program, which strangely enough insists on linking against the host's libraries 
-(libgd, libpng, libz, and so forth). </para></listitem>
+<listitem><para>This prevents the build of the
+<command>memusagestat</command> program, which insists on linking
+against the host's libraries (libgd, libpng, libz,
+etc.).</para></listitem>
 </varlistentry>
 
 <varlistentry>
 <term><parameter>--without-cvs</parameter></term>
-<listitem><para>This is meant to prevent
-the Makefiles from attempting automatic CVS checkouts when using a CVS
-snapshot. But it's not actually needed these days. We use it because it
-suppresses an annoying but harmless warning about a missing
-<command>autoconf</command> program.</para></listitem>
+<listitem><para>This is meant to prevent the Makefile files from
+attempting automatic CVS checkouts when using a CVS snapshot. While
+this command is not required, it is recommended because it suppresses
+an annoying, but harmless, warning about a missing autoconf
+program.</para></listitem>
 </varlistentry>
 
 <varlistentry>
 <term><parameter>--with-headers=/tools/glibc-kernheaders</parameter></term>
-<listitem><para>This tells Glibc to compile against the <quote>raw</quote> 
+<listitem><para>This tells Glibc to compile itself against the <quote>raw</quote> 
 kernel headers, so that it knows exactly what features the kernel has, and can 
-optimize itself accordingly.  Not strictly necessary, but nice to have.</para></listitem>
+optimize itself accordingly. Not strictly necessary, but nice to use.</para></listitem>
 </varlistentry>
 </variablelist>
 
@@ -123,72 +127,81 @@ optimize itself accordingly.  Not strictly necessary, but nice to have.</para></
 *** Check the INSTALL file for required versions.</computeroutput></screen></blockquote>
 
 <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>
+generally harmless, but it is believed it can sometimes cause issues when
+running the test suite. <command>msgfmt</command> is part of the
+Gettext package which your distribution should provide. If you do have
+<command>msgfmt</command> but it is deemed incompatible, you have the
+option to upgrade your host system's Gettext package, or you can
+continue without it and see if the test suite runs without problems
+regardless.</para>
 
 <para>Compile the package:</para>
 
 <screen><userinput>make</userinput></screen>
 
-<para>Compilation is now complete. As mentioned earlier, running the test suites
-for the temporary tools installed in this chapter is not mandatory. If you want
-to run the Glibc test suite though, the following command will do so:</para>
+<para>Compilation is now complete. As mentioned earlier, running the
+test suites for the temporary tools installed in this chapter is not
+mandatory. To run the Glibc test suite (if desired), the following
+command will do so:</para>
 
 <screen><userinput>make check</userinput></screen>
 
 <para>For a discussion of test failures that are of particular
 importance, please see <xref linkend="ch-system-glibc"/>.</para>
 
-<para>In this chapter, some tests can be adversely affected by existing tools or
-environmental issues on the host system.  In short, don't worry too much if you
-see Glibc test suite failures 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).</para>
-
-<para>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>. If you do that though, 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>
+<para>In this chapter, some tests can be adversely affected by
+existing tools or environmental issues on the host system. Glibc test
+suite failures in this chapter are not typically worrisome. The Glibc
+installed in <xref linkend="chapter-building-system"/> is the one that
+will ultimately end up being used, so that is the one that should pass
+most tests (even in <xref linkend="chapter-building-system"/>, some
+failures could still occur, for example, with the math tests).</para>
+
+<para>When experiencing a failure, make a note of it, then continue by
+reissuing the <command>make check</command> command. The test suite should pick up where it left
+off and continue. This stop-start sequence can be circumvented by
+issuing a <command>make -k check</command> command. If using this option, be sure to log the
+output so that the log file can be examined for failures later.</para>
+
+<para>The install stage of Glibc will issue a harmless warning at the
+end about the absence of /tools/etc/ld.so.conf. Prevent this warning
+with:</para>
 
 <screen><userinput>mkdir /tools/etc
 touch /tools/etc/ld.so.conf</userinput></screen>
 
-<para>Now install the package:</para>
+<para>Install the package:</para>
 
 <screen><userinput>make install</userinput></screen>
 
-<para>Different countries and cultures have varying conventions for how to
-communicate. These conventions range from very simple ones, such as the format
-for representing dates and times, to very complex ones, such as the language
-spoken. The <quote>internationalization</quote> of GNU programs works by means
-of <emphasis>locales</emphasis>.</para>
+<para>Different countries and cultures have varying conventions for
+how to communicate. These conventions range from the format for
+representing dates and times to more complex ones, such as the
+language spoken. The <quote>internationalization</quote> of GNU programs works by
+locale.</para>
 
-<note><para>If you are not running the test suites here in this chapter as per
-our recommendation, there is little point in installing the locales now. We'll
-be installing the locales in the next chapter.</para></note>
+<note><para>If the test suites are not being run in this chapter (as
+per the recommendation), there is no need to install the locales now.
+The appropriate locales will be installed in the next
+chapter.</para></note>
 
-<para>If you still want to install the Glibc locales anyway, the following
-command will do so:</para>
+<para>To install the Glibc locales anyway, use the following
+command:</para>
 
 <screen><userinput>make localedata/install-locales</userinput></screen>
 
-<para>An alternative to running the previous command is to install only those
-locales which you need or want. This can be achieved by using the
-<command>localedef</command> command. Information on this can be found in
-the <filename>INSTALL</filename> file in the Glibc source. However, there are
-a number of locales that are essential for the tests of future packages to
-pass, in particular, the <emphasis>libstdc++</emphasis> tests from GCC. The
-following instructions, instead of the install-locales target above, will
-install the minimum set of locales necessary for the tests to run
-successfully:</para>
+<para>To save yourself a lot of time, an alternative to running the
+previous command (which generates and installs every locale Glibc is
+aware of) is to install only those locales that are wanted and needed.
+This can be achieved by using the <command>localedef</command>
+command. Information on this command is located in the
+<filename>INSTALL</filename> file in the Glibc source.  However, there
+are a number of locales that are essential in order for the tests of
+future packages to pass, in particular, the
+<emphasis>libstdc++</emphasis> tests from GCC. The following
+instructions, instead of the <emphasis>install-locales</emphasis>
+target used above, will install the minimum set of locales necessary
+for the tests to run successfully:</para>
 
 <screen><userinput>mkdir -p /tools/lib/locale
 localedef -i de_DE -f ISO-8859-1 de_DE
@@ -210,3 +223,4 @@ localedef -i ja_JP -f EUC-JP ja_JP</userinput></screen>
 </sect2>
 
 </sect1>
+
diff --git a/chapter05/grep.xml b/chapter05/grep.xml
index 9fcdaca18..512c245d7 100644
--- a/chapter05/grep.xml
+++ b/chapter05/grep.xml
@@ -37,16 +37,18 @@
 <variablelist>
 <varlistentry>
 <term><parameter>--disable-perl-regexp</parameter></term>
-<listitem><para>This makes sure that <command>grep</command> does not 
-get linked against a PCRE library that may be present on the host and would not be 
-available once we enter the chroot environment.</para></listitem>
+<listitem><para>This makes sure that the <command>grep</command>
+program does not get linked against a Perl Compatible Regular
+Expression (PCRE) library that may be present on the host and would
+not be available once we enter the chroot
+environment.</para></listitem>
 </varlistentry>
 
 <varlistentry>
 <term><parameter>--with-included-regex</parameter></term>
-<listitem><para>This ensures that
-Grep uses its internal regular expression code. Without this switch, Grep will
-use the code from Glibc, which is known to be slightly buggy.</para></listitem>
+<listitem><para>This ensures that Grep uses its internal regular
+expression code.  Without this switch, Grep will use the code from
+Glibc, which is known to be buggy.</para></listitem>
 </varlistentry>
 </variablelist>
 
@@ -54,10 +56,10 @@ use the code from Glibc, which is known to be slightly buggy.</para></listitem>
 
 <screen><userinput>make</userinput></screen>
 
-<para>(If you want to test the results, then issue:
-<userinput>make check</userinput>.)</para>
+<para>To test the results, issue: <userinput>make
+check</userinput>.</para>
 
-<para>Then install them and their documentation:</para>
+<para>Install the package:</para>
 
 <screen><userinput>make install</userinput></screen>
 
@@ -68,3 +70,4 @@ use the code from Glibc, which is known to be slightly buggy.</para></listitem>
 </sect2>
 
 </sect1>
+
diff --git a/chapter05/gzip.xml b/chapter05/gzip.xml
index 045648cf4..e4b88264c 100644
--- a/chapter05/gzip.xml
+++ b/chapter05/gzip.xml
@@ -35,7 +35,7 @@
 
 <screen><userinput>make</userinput></screen>
 
-<para>And install it:</para>
+<para>Install the package:</para>
 
 <screen><userinput>make install</userinput></screen>
 
@@ -46,3 +46,4 @@
 </sect2>
 
 </sect1>
+
diff --git a/chapter05/hostreqs.xml b/chapter05/hostreqs.xml
index fb34e8db7..830ed7654 100644
--- a/chapter05/hostreqs.xml
+++ b/chapter05/hostreqs.xml
@@ -4,23 +4,23 @@
   %general-entities;
 ]>
 <sect1 id="ch-tools-hostreqs">
-<title>Host system requirements</title>
+<title>Host System Requirements</title>
 <?dbhtml filename="hostreqs.html"?>
 
-<para>Due to the experimental nature of the current book, the host must be
-running at <emphasis>least</emphasis> a 2.6.2 kernel compiled with GCC-3.0 or
-higher. There are two main reasons for the high requirement.  Firstly, we make
-use of the Native Posix Threading Library (NPTL) whose testsuite will segfault
-if the host's kernel hasn't been compiled with GCC-3.0 or later.  Secondly, the
-2.6.2 or later version of the kernel is required for the use of Udev. Udev
-creates devices dynamically by reading from the
-<systemitem class="filesystem">sysfs</systemitem> file system. Only very
-recently has support for this file system been implemented in most of the kernel
-drivers, however. We must be sure that all the critical system devices get
-created properly.</para>
-
-<para>In order to check that your host kernel meets the requirements outlined
-above, you can run the following command:</para>
+<para>The host must be running at least a 2.6.2 kernel compiled with
+GCC-3.0 or higher. There are two main reasons for this high
+requirement. First, the Native Posix Threading Library (NPTL)
+testsuite will segfault if the host's kernel hasn't been compiled with
+GCC-3.0 or a later version. Secondly, the 2.6.2 or later version of
+the kernel is required for the use of Udev. Udev creates devices
+dynamically by reading from the <systemitem
+class="filesystem">sysfs</systemitem> file system. However, only
+recently has support for this file system been implemented in most of
+the kernel drivers. We must be sure that all critical system devices
+get created properly.</para>
+
+<para>In order to determine whether the host kernel meets the
+requirements outlined above, run the following command:</para>
 
 <screen><userinput>cat /proc/version</userinput></screen>
 
@@ -28,10 +28,12 @@ above, you can run the following command:</para>
 
 <blockquote><screen><computeroutput>Linux version 2.6.2 (user@host) (gcc version 3.4.0) #1 Tue Apr 20 21:22:18 GMT 2004</computeroutput></screen></blockquote>
 
-<para>If the results of the above command state that your host kernel wasn't
-compiled using a GCC-3.0 (or later) compiler, you will need to compile one
-yourself, and reboot your host to use the newly compiled kernel. Instructions
-for compiling the kernel and configuring the bootloader (assuming your host uses
-GRUB) are given in <xref linkend="chapter-bootable"/>.</para>
+<para>If the results of the above command state that the host kernel
+was not compiled using a GCC-3.0 (or later) compiler, one will need to
+be compiled.  The host system will then need to be rebooted to use the
+newly compiled kernel. Instructions for compiling the kernel and
+configuring the bootloader (assuming your host uses GRUB) are located
+in <xref linkend="chapter-bootable"/>.</para>
 
 </sect1>
+
diff --git a/chapter05/introduction.xml b/chapter05/introduction.xml
index 78c883ecd..2a1c368a3 100644
--- a/chapter05/introduction.xml
+++ b/chapter05/introduction.xml
@@ -7,58 +7,62 @@
 <title>Introduction</title>
 <?dbhtml filename="introduction.html"?>
 
-<para>In this chapter we will compile and install a minimal
-Linux system. This system will contain just enough tools to be able
-to start constructing the final LFS system in the next chapter and allow
-a working environment with a little more user convenience than a minimum
-environment.</para>
+<para>This chapter shows how to compile and install a minimal Linux
+system. This system will contain just enough tools to start
+constructing the final LFS system in <xref
+linkend="chapter-building-system"/> and allow a working environment
+with more user convenience than a minimum environment would.</para>
 
-<para>The building of this minimal system is done in two steps: first we
-build a brand-new and host-independent toolchain (compiler, assembler,
-linker, libraries, and a few useful utilities), and then use this to build all the other essential
-tools.</para>
+<para>There are two steps in building this minimal system. The first
+step is to build a new and host-independent toolchain (compiler,
+assembler, linker, libraries, and a few useful utilities).  The second
+step uses this toolchain to build the other essential tools.</para>
 
 <para>The files compiled in this chapter will be installed under the
-<filename class="directory">$LFS/tools</filename> directory
-to keep them separate from the files installed in the next chapter and your host's production directories.
-Since the packages compiled here are merely temporary, we don't want
-them to pollute the soon-to-be LFS system.</para>
+<filename class="directory">$LFS/tools</filename> directory to keep
+them separate from the files installed in the next chapter and the
+host production directories. Since the packages compiled here are
+temporary, we don't want them to pollute the soon-to-be LFS
+system.</para>
 
-<para>Before issuing the build instructions for a package, you are expected to
-have already unpacked it (explained shortly) as user <emphasis>lfs</emphasis>,
-and to have performed a <userinput>cd</userinput> into the created directory.
-The build instructions assume that you are using the <command>bash</command>
-shell.</para>
+<para>Before issuing the build instructions for a package, the package
+should be unpacked (explained shortly) as user
+<emphasis>lfs</emphasis>, and a <command>cd</command> into the
+created directory should be performed. The build instructions assume
+that the <command>bash</command> shell is in use.</para>
 
-<para>Several of the packages are patched before compilation, but only when
-the patch is needed to circumvent a problem. Often the patch is needed in
-both this and the next chapter, but sometimes in only one of them. Therefore,
-don't worry when instructions for a downloaded patch seem to be missing. Also,
-when applying a patch, you'll occasionally see warning messages about
-<emphasis>offset</emphasis> or <emphasis>fuzz</emphasis>. These warnings are
-nothing to worry about, as the patch was still successfully applied.</para>
+<para>Several of the packages are patched before compilation, but only
+when the patch is needed to circumvent a problem. A patch is often
+needed in both this and the next chapter, but sometimes in only one or
+the other. Therefore, do not be concerned if instructions for a downloaded
+patch seem to be missing. Warning messages about
+<emphasis>offset</emphasis> or <emphasis>fuzz</emphasis> may
+also be encountered when applying a patch. Do not worry about these
+warnings, as the patch was still successfully applied.</para>
 
-<para>During the compilation of most packages you will see many warnings
-scroll by on your screen. These are normal and can safely be ignored. They are
-just what they say they are: warnings -- mostly about deprecated, but not
-invalid, use of the C or C++ syntax. It's just that C standards have changed
-rather often and some packages still use the older standard, which is not
-really a problem.</para>
+<para>During the compilation of most packages, there will be several
+warnings that scroll by on the screen. These are normal and can safely
+be ignored. These warnings are as they appear -- warnings about
+deprecated, but not invalid, use of the C or C++ syntax. C standards
+change fairly often, and some packages still use the older standard,
+which is not a problem but does prompt the warning.</para>
 
-<para>After installing each package you should delete its source and build
-directories, <emphasis>unless</emphasis> told otherwise. Deleting the sources
-saves space, but also prevents mis-configuration when the same package is
-reinstalled further on. Only for three packages you will need to keep the
-source and build directories around for a while, so their contents can be used
-by later commands. Do not miss the reminders.</para>
+<para>After installing each package, delete its source and build
+directories, unless specifically instructed otherwise. Deleting the
+sources saves space and prevents mis-configuration when the same
+package is reinstalled later on. Only three of the packages need to
+retain the source and build directories in order for their contents to
+be used by later commands. Pay special attention to these
+reminders.</para>
 
-<para>Now first check that your LFS environment variable is set up
+<para>Check one last time that the LFS environment variable is set up
 properly:</para>
 
 <screen><userinput>echo $LFS</userinput></screen>
 
-<para>Make sure the output shows the path to your LFS partition's mount
-point, which is <filename class="directory">/mnt/lfs</filename> if you
-followed our example.</para>
+<para>Make sure the output shows the path to the LFS partition's mount
+point, which is <filename class="directory">/mnt/lfs</filename>, using
+our example.</para>
 
 </sect1>
+
diff --git a/chapter05/kernel-headers.xml b/chapter05/kernel-headers.xml
index d18ac0020..86ae65399 100644
--- a/chapter05/kernel-headers.xml
+++ b/chapter05/kernel-headers.xml
@@ -19,23 +19,29 @@
 <seglistitem><seg>0.1 SBU</seg><seg>186 MB</seg></seglistitem>
 </segmentedlist>
 
+<segmentedlist>
+<segtitle>Linux Headers installation depends on</segtitle>
+<seglistitem><seg>Coreutils, Make</seg></seglistitem>
+</segmentedlist>
+
 </sect2>
 
 <sect2 role="installation">
 <title>Installation of the kernel headers</title>
 
-<para>As some packages need to refer to the kernel header files, we're going
-to unpack the kernel archive now, set it up, and copy the required files to a
-place where <command>gcc</command> can later find them.</para>
+<para>Because some packages need to refer to the kernel header files,
+now is a good time to unpack the kernel archive, set it up, and copy
+the required files to a place where <command>gcc</command> can locate
+them later.</para>
 
 <para>Prepare for the header installation with:</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
-un-tarring.</para>
+<para>This ensures that the kernel tree is absolutely clean. It is
+recommended that this command be issued prior to
+<emphasis>each</emphasis> kernel compilation. Do not assume that the
+source tree is automatically clean after un-tarring.</para>
 
 <para>Create the <filename>include/linux/version.h</filename> file:</para>
 
@@ -59,3 +65,4 @@ cp -R include/asm-generic /tools/glibc-kernheaders</userinput></screen>
 </sect2>
 
 </sect1>
+
diff --git a/chapter05/linux-libc-headers.xml b/chapter05/linux-libc-headers.xml
index a74ce26e3..a882e5d9e 100644
--- a/chapter05/linux-libc-headers.xml
+++ b/chapter05/linux-libc-headers.xml
@@ -24,17 +24,27 @@
 <sect2 role="installation">
 <title>Installation of Linux-Libc-Headers</title>
 
-<para>For years it has been common practice to use so-called <quote>raw</quote>
-kernel headers (straight from a kernel tarball) in <filename class="directory">/usr/include</filename>, but over the
-last few years, the kernel developers have taken a strong stance that such
-things should not be done.  Thus was born the linux-libc-headers project,
-designed to maintain an API stable version of the Linux headers.</para>
+<para>For years it has been common practice to use <quote>raw</quote> kernel
+headers (straight from a kernel tarball) in <filename
+class="directory">/usr/include</filename>, but over the
+last few years, the kernel developers have taken a strong stance that
+this should not be done. This gave birth to the linux-libc-headers
+project, which was designed to maintain an Application Programming
+Interface (API) stable version of the Linux headers.</para>
 
 <para>Install the header files:</para>
 
 <screen><userinput>cp -R include/asm-i386 /tools/include/asm
 cp -R include/linux /tools/include</userinput></screen>
 
+<para>If your architecture is not i386 (compatible), adjust the first command
+accordingly.</para>
+
+</sect2>
+
+<sect2 role="content"><title/>
+<para>The details on this package are found in <xref linkend="contents-linux-libc-headers"/>.</para>
 </sect2>
 
 </sect1>
+
diff --git a/chapter05/m4.xml b/chapter05/m4.xml
index 5907e5cfc..7b77556c8 100644
--- a/chapter05/m4.xml
+++ b/chapter05/m4.xml
@@ -35,10 +35,10 @@
 
 <screen><userinput>make</userinput></screen>
 
-<para>To test the results, issue:
-<userinput>make check</userinput>.</para>
+<para>To test the results, issue: <userinput>make
+check</userinput>.</para>
 
-<para>Now install the package:</para>
+<para>Install the package:</para>
 
 <screen><userinput>make install</userinput></screen>
 
@@ -49,3 +49,4 @@
 </sect2>
 
 </sect1>
+
diff --git a/chapter05/make.xml b/chapter05/make.xml
index 2d8bccdcf..a231036e7 100644
--- a/chapter05/make.xml
+++ b/chapter05/make.xml
@@ -35,10 +35,10 @@
 
 <screen><userinput>make</userinput></screen>
 
-<para>(If you want to test the results, then issue:
-<userinput>make check</userinput>.)</para>
+<para>To test the results, issue: <userinput>make
+check</userinput>.</para>
 
-<para>Then install it and its documentation:</para>
+<para>Install the package:</para>
 
 <screen><userinput>make install</userinput></screen>
 
@@ -49,3 +49,4 @@
 </sect2>
 
 </sect1>
+
diff --git a/chapter05/ncurses.xml b/chapter05/ncurses.xml
index 9bc86e181..00778efa0 100644
--- a/chapter05/ncurses.xml
+++ b/chapter05/ncurses.xml
@@ -37,18 +37,19 @@
 <variablelist>
 <varlistentry>
 <term><parameter>--without-ada</parameter></term>
-<listitem><para>This tells Ncurses not
-to build its Ada bindings, even if an Ada compiler is installed on the host.
-This must be done because once we enter the chroot environment, Ada will no
-longer be available.</para></listitem>
+<listitem><para>This tells Ncurses not to build its Ada bindings, even
+if an Ada compiler is installed on the host. This needs to be done
+because once we enter the chroot environment, Ada will no longer be
+available.</para></listitem>
 </varlistentry>
 
 <varlistentry>
 <term><parameter>--enable-overwrite</parameter></term>
-<listitem><para>This tells Ncurses to install its header files into 
-<filename class="directory">/tools/include</filename> instead of 
-<filename class="directory">/tools/include/ncurses</filename> to ensure that 
-other packages can find the Ncurses headers successfully.</para></listitem>
+<listitem><para>This tells Ncurses to install its header files into
+<filename class="directory">/tools/include</filename>, instead of
+<filename class="directory">/tools/include/ncurses</filename>, to
+ensure that other packages can find the Ncurses headers
+successfully.</para></listitem>
 </varlistentry>
 </variablelist>
 
@@ -56,7 +57,7 @@ other packages can find the Ncurses headers successfully.</para></listitem>
 
 <screen><userinput>make</userinput></screen>
 
-<para>Then install them and their documentation:</para>
+<para>Install the package:</para>
 
 <screen><userinput>make install</userinput></screen>
 
@@ -67,3 +68,4 @@ other packages can find the Ncurses headers successfully.</para></listitem>
 </sect2>
 
 </sect1>
+
diff --git a/chapter05/patch.xml b/chapter05/patch.xml
index 6f7fa5746..57e1d6593 100644
--- a/chapter05/patch.xml
+++ b/chapter05/patch.xml
@@ -27,9 +27,9 @@
 <sect2 role="installation">
 <title>Installation of Patch</title>
 
-<para>Prepare Patch for compilation (the preprocessor flag
-<parameter>-D_GNU_SOURCE</parameter> is only needed on the PowerPC platform, on
-other architectures you can leave it out):</para>
+<para>Prepare Patch for compilation.  The preprocessor flag
+<parameter>-D_GNU_SOURCE</parameter> is only needed on the PowerPC
+platform, on other architectures it can be left it out:</para>
 
 <screen><userinput>CPPFLAGS=-D_GNU_SOURCE ./configure --prefix=/tools</userinput></screen>
 
@@ -37,7 +37,7 @@ other architectures you can leave it out):</para>
 
 <screen><userinput>make</userinput></screen>
 
-<para>Then install it and its documentation:</para>
+<para>Install the package:</para>
 
 <screen><userinput>make install</userinput></screen>
 
@@ -48,3 +48,4 @@ other architectures you can leave it out):</para>
 </sect2>
 
 </sect1>
+
diff --git a/chapter05/perl.xml b/chapter05/perl.xml
index c0de05a45..eea7e2972 100644
--- a/chapter05/perl.xml
+++ b/chapter05/perl.xml
@@ -27,12 +27,13 @@
 <sect2 role="installation">
 <title>Installation of Perl</title>
 
-<para>First adapt some hard-wired paths to the C library:</para>
+<para>First adapt some hard-wired paths to the C library by applying
+the following patch:</para>
 
 <screen><userinput>patch -Np1 -i ../perl-&perl-version;-libc-1.patch</userinput></screen>
 
 <para>Now prepare Perl for compilation (make sure you get the 'IO Fcntl POSIX'
-right, they are all letters):</para>
+part of the command correct -- they are all letters):</para>
 
 <screen><userinput>./configure.gnu --prefix=/tools -Dstatic_ext='IO Fcntl POSIX'</userinput></screen>
 
@@ -41,9 +42,9 @@ right, they are all letters):</para>
 <variablelist>
 <varlistentry>
 <term><parameter>-Dstatic_ext='IO Fcntl POSIX'</parameter></term>
-<listitem><para>This tells
-Perl to build the minimum set of static extensions needed for installing and
-testing the Coreutils package in the next chapter.</para></listitem>
+<listitem><para>This tells Perl to build the minimum set of static
+extensions needed for installing and testing the Coreutils package in
+the next chapter.</para></listitem>
 </varlistentry>
 </variablelist>
 
@@ -64,3 +65,4 @@ cp -R lib/* /tools/lib/perl5/&perl-version;</userinput></screen>
 </sect2>
 
 </sect1>
+
diff --git a/chapter05/sed.xml b/chapter05/sed.xml
index 265486c96..3be9c3f6f 100644
--- a/chapter05/sed.xml
+++ b/chapter05/sed.xml
@@ -35,10 +35,10 @@
 
 <screen><userinput>make</userinput></screen>
 
-<para>(If you want to test the results, then issue:
-<userinput>make check</userinput>.)</para>
+<para>To test the results, issue: <userinput>make
+check</userinput>.</para>
 
-<para>Then install it and its documentation:</para>
+<para>Install the package:</para>
 
 <screen><userinput>make install</userinput></screen>
 
@@ -49,3 +49,4 @@
 </sect2>
 
 </sect1>
+
diff --git a/chapter05/stripping.xml b/chapter05/stripping.xml
index 935f848e6..d6c4e12be 100644
--- a/chapter05/stripping.xml
+++ b/chapter05/stripping.xml
@@ -7,29 +7,32 @@
 <title>Stripping</title>
 <?dbhtml filename="stripping.html"?>
 
-<para>The steps in this section are optional, but if your LFS partition is
-rather small, you will be glad to learn that you can remove some unnecessary
-things. The executables and libraries you have built so far contain about 130
-MB of unneeded debugging symbols. Remove those symbols with:</para>
+<para>The steps in this section are optional, but if the LFS partition
+is rather small, it is beneficial to learn that unnecessary items can
+be removed. The executables and libraries built so far contain about
+130 MB of unneeded debugging symbols. Remove those symbols
+with:</para>
 
 <screen><userinput>strip --strip-debug /tools/lib/*
 strip --strip-unneeded /tools/{,s}bin/*</userinput></screen>
 
-<para>The last of the above commands will skip some twenty files, reporting
-that it doesn't recognize their file format. Most of them are scripts instead
-of binaries.</para>
+<para>The last of the above commands will skip some twenty files,
+reporting that it does not recognize their file format. Most of these
+are scripts instead of binaries.</para>
 
 <para>Take care <emphasis>not</emphasis> to use
-<parameter>--strip-unneeded</parameter> on the libraries -- the static ones
-would be destroyed and you would have to build the three toolchain packages
-all over again.</para>
+<parameter>--strip-unneeded</parameter> on the libraries.  The static
+ones would be destroyed and the toolchain packages would need to be
+built all over again.</para>
 
-<para>To save another 30 MB, you can remove all the documentation:</para>
+<para>To save another 30 MB, remove all the documentation:</para>
 
 <screen><userinput>rm -rf /tools/{doc,info,man}</userinput></screen>
 
-<para>You will now need to have at least 850 MB of free space on your LFS
-file system to be able to build and install Glibc in the next phase. If you can
-build and install Glibc, you can build and install the rest too.</para>
+<para>There will now be at least 850 MB of free space on the LFS file
+system that can be used to build and install Glibc in the next phase.
+If you can build and install Glibc, you can build and install the rest
+too.</para>
 
 </sect1>
+
diff --git a/chapter05/tar.xml b/chapter05/tar.xml
index 62896f359..fac6e6a46 100644
--- a/chapter05/tar.xml
+++ b/chapter05/tar.xml
@@ -35,10 +35,10 @@
 
 <screen><userinput>make</userinput></screen>
 
-<para>(If you want to test the results, then issue:
-<userinput>make check</userinput>.)</para>
+<para>To test the results, issue: <userinput>make
+check</userinput>.</para>
 
-<para>Then install them and their documentation:</para>
+<para>Install the package:</para>
 
 <screen><userinput>make install</userinput></screen>
 
@@ -49,3 +49,4 @@
 </sect2>
 
 </sect1>
+
diff --git a/chapter05/tcl.xml b/chapter05/tcl.xml
index 381cec992..af23aacca 100644
--- a/chapter05/tcl.xml
+++ b/chapter05/tcl.xml
@@ -29,13 +29,15 @@ GCC, Glibc, Grep, Make, Sed</seg></seglistitem>
 <sect2 role="installation">
 <title>Installation of Tcl</title>
 
-<para>This package and the next two are only installed to support running 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 the
-the test suites are not run in this chapter (we recommend not running them),
-these packages are still required to run the test suites in the next
-chapter.</para>
+<para>This package and the next two (Expect and DejaGNU)
+are
+installed to support running the test suites for GCC and Binutils.
+Installing three packages for testing purposes may seem excessive, but
+it is very reassuring, if not essential, to know that the most
+important tools are working properly. Even if the test suites are not
+run in this chapter (we recommend not running them), these packages
+are still required to run the test suites in <xref
+linkend="chapter-building-system"/>.</para>
 
 <para>Prepare Tcl for compilation:</para>
 
@@ -46,21 +48,22 @@ chapter.</para>
 
 <screen><userinput>make</userinput></screen>
 
-<para>If you want to test the results, then issue:
-<userinput>TZ=UTC make test</userinput>. However, the Tcl test suite is known
-to experience failures under certain host conditions that are not fully
-understood. Therefore, test suite failures here are not surprising, and are not
-considered critical. The <parameter>TZ=UTC</parameter> parameter sets the time
-zone to Coordinated Universal Time (UTC) also known as Greenwich Mean Time
-(GMT), but only for the duration of the test suite run. This ensures the clock
-tests are exercised correctly. More information on the TZ environment variable
-will be given later on in <xref linkend="chapter-bootscripts"/>.</para>
+<para>To test the results, issue: <userinput>TZ=UTC make
+test</userinput>. However, the Tcl test
+suite is known to experience failures under certain host conditions
+that are not fully understood. Therefore, test suite failures here are not surprising, and are not
+considered critical. The <parameter>TZ=UTC</parameter> parameter sets the time zone to
+Coordinated Universal Time (UTC), also known as Greenwich Mean Time
+(GMT), but only for the duration of the test suite run. This ensures
+that the clock tests are exercised correctly. More information on the
+TZ environment variable will be provided in <xref
+linkend="chapter-bootscripts"/>.</para>
 
 <para>Install the package:</para>
 
 <screen><userinput>make install</userinput></screen>
 
-<warning><para><emphasis>Do not remove</emphasis> the
+<warning><para><emphasis>Do not</emphasis> remove the
 <filename class="directory">tcl&tcl-version;</filename> source directory yet, as the next package
 will need its internal headers.</para></warning>
 
@@ -84,7 +87,7 @@ will need its internal headers.</para></warning>
 <term><command>tclsh8.4</command></term>
 <listitem>
 <indexterm zone="ch-tools-tcl tclsh8.4"><primary sortas="b-tclsh8.4">tclsh8.4</primary></indexterm>
-<para>is the Tcl command shell.</para>
+<para>the Tcl command shell.</para>
 </listitem>
 </varlistentry>
 
@@ -92,7 +95,7 @@ will need its internal headers.</para></warning>
 <term><filename class="libraryfile">libtcl8.4.so</filename></term>
 <listitem>
 <indexterm zone="ch-tools-tcl libtcl8.4.so"><primary sortas="c-libtcl8.4.so">libtcl8.4.so</primary></indexterm>
-<para>is the Tcl library.</para>
+<para>the Tcl library.</para>
 </listitem>
 </varlistentry>
 </variablelist>
@@ -100,3 +103,4 @@ will need its internal headers.</para></warning>
 </sect2>
 
 </sect1>
+
diff --git a/chapter05/texinfo.xml b/chapter05/texinfo.xml
index d5e4faeac..2336412f8 100644
--- a/chapter05/texinfo.xml
+++ b/chapter05/texinfo.xml
@@ -35,10 +35,10 @@
 
 <screen><userinput>make</userinput></screen>
 
-<para>(If you want to test the results, then issue:
-<userinput>make check</userinput>.)</para>
+<para>To test the results, issue: <userinput>make
+check</userinput>.</para>
 
-<para>Then install them and their documentation:</para>
+<para>Install the package:</para>
 
 <screen><userinput>make install</userinput></screen>
 
@@ -49,3 +49,4 @@
 </sect2>
 
 </sect1>
+
diff --git a/chapter05/toolchaintechnotes.xml b/chapter05/toolchaintechnotes.xml
index 666e181e2..d10878dbb 100644
--- a/chapter05/toolchaintechnotes.xml
+++ b/chapter05/toolchaintechnotes.xml
@@ -4,200 +4,218 @@
   %general-entities;
 ]>
 <sect1 id="ch-tools-toolchaintechnotes">
-<title>Toolchain technical notes</title>
+<title>Toolchain Technical Notes</title>
 <?dbhtml filename="toolchaintechnotes.html"?>
 
-<para>This section attempts to explain some of the rationale and technical
-details behind the overall build method. It's not essential that you understand
-everything here immediately. Most of it will make sense once you have performed
-an actual build. Feel free to refer back here at any time.</para>
-
-<para>The overall goal of <xref linkend="chapter-temporary-tools"/> is to provide a sane,
-temporary environment that we can chroot into, and from which we can produce a
-clean, trouble-free build of the target LFS system in
-<xref linkend="chapter-building-system"/>. Along the way, we attempt to divorce ourselves
-from the host system as much as possible, and in so doing build a
-self-contained and self-hosted toolchain. It should be noted that the
-build process has been designed to minimize the risks for
-new readers and provide maximum educational value at the same time. In other
-words, more advanced techniques could be used to build the system.</para>
+<para>This section explains some of the rationale and technical
+details behind the overall build method. It is not essential to
+immediately understand everything in this section. Most of this
+information will be clearer after performing an actual build. This
+section can be referred back to at any time during the process.</para>
+
+<para>The overall goal of <xref linkend="chapter-temporary-tools"/> is
+to provide a temporary environment that can be chrooted into and from
+which can be produced a clean, trouble-free build of the target LFS
+system in <xref linkend="chapter-building-system"/>. Along the way, we
+separate from the host system as much as possible, and in doing so,
+build a self-contained and self-hosted toolchain. It should be noted
+that the build process has been designed to minimize the risks for new
+readers and provide maximum educational value at the same time. In
+other words, more advanced techniques could be used to build the
+system.</para>
 
 <important>
-<para>Before continuing, you really should be aware of the name of your working
-platform, often also referred to as the <emphasis>target triplet</emphasis>. For
-many folks the target triplet will probably be
-<emphasis>i686-pc-linux-gnu</emphasis>. A simple way to determine your target
-triplet is to run the <command>config.guess</command> script that comes with
-the source for many packages. Unpack the Binutils sources and run the script:
+<para>Before continuing, be aware of the name of the working platform,
+often referred to as the target triplet. Many times, the target
+triplet will probably be <emphasis>i686-pc-linux-gnu</emphasis>. A
+simple way to determine the name of the target triplet is to run the
+<command>config.guess</command> script that comes with the source for
+many packages. Unpack the Binutils sources and run the script:
 <userinput>./config.guess</userinput> and note the output.</para>
 
-<para>You'll also need to be aware of the name of your platform's
-<emphasis>dynamic linker</emphasis>, often also referred to as the
-<emphasis>dynamic loader</emphasis>, not to be confused with the standard linker
-<command>ld</command> that is part of Binutils. The dynamic linker is provided
-by Glibc and has the job of finding and loading the shared libraries needed by a
-program, preparing the program to run and then running it. For most folks the
-name of the dynamic linker will be <filename>ld-linux.so.2</filename>. On
-platforms that are less prevalent, the name might be
-<filename>ld.so.1</filename> and newer 64 bit platforms might even have
-something completely different. You should be able to determine the name
-of your platform's dynamic linker by looking in the
-<filename class="directory">/lib</filename> directory on your host system. A
-sure-fire way is to inspect a random binary from your host system by running:
-<userinput>readelf -l &lt;name of binary&gt; | grep interpreter</userinput>
-and noting the output. The authoritative reference covering all platforms is in
-the <filename>shlib-versions</filename> file in the root of the Glibc source
-tree.</para>
+<para>Also be aware of the name of the platform's dynamic linker,
+often referred to as the dynamic loader (not to be confused with the
+standard linker <command>ld</command> that is part of Binutils). The
+dynamic linker is provided by Glibc finds and loads the shared
+libraries needed by a program, prepares the program to run, and then
+runs it. The name of the dynamic linker will usually be
+<filename>ld-linux.so.2</filename>. On platforms that are less
+prevalent, the name might be <filename>ld.so.1</filename>, and newer
+64 bit platforms might be named something else entirely. The name of
+the platform's dynamic linker can be determined by looking in the
+<filename class="directory">/lib</filename> directory on the host
+system. A sure-fire way is to inspect a random binary from the host
+system by running: <userinput>readelf -l &lt;name of binary&gt; | grep
+interpreter</userinput> and noting the output. The authoritative
+reference covering all platforms is in the
+<filename>shlib-versions</filename> file in the root of the Glibc
+source tree.</para>
 </important>
 
 <para>Some key technical points of how the <xref linkend="chapter-temporary-tools"/> build
 method works:</para>
 
 <itemizedlist>
-<listitem><para>Similar in principle to cross compiling whereby tools installed
-into the same prefix work in cooperation and thus utilize a little GNU
+<listitem><para>The process is similar in principle to
+cross-compiling, whereby tools installed in the same prefix work in
+cooperation, and thus utilize a little GNU
 <quote>magic</quote>.</para></listitem>
 
-<listitem><para>Careful manipulation of the standard linker's library search
-path to ensure programs are linked only against libraries we
-choose.</para></listitem>
+<listitem><para>Careful manipulation of the standard linker's library
+search path ensures programs are linked only against chosen
+libraries</para></listitem>
 
 <listitem><para>Careful manipulation of <command>gcc</command>'s
 <filename>specs</filename> file to tell the compiler which target dynamic
-linker will be used.</para></listitem>
+linker will be used</para></listitem>
 </itemizedlist>
 
-<para>Binutils is installed first because the <command>./configure</command> runs of both GCC and Glibc perform various
-feature tests on the assembler and linker
-to determine which software features to enable
-or disable. This is more important than one might first realize. An incorrectly
-configured GCC or Glibc can result in a subtly broken toolchain where the impact
-of such breakage might not show up until near the end of the build of a whole
-distribution. Thankfully, a test suite failure will usually alert us before too
-much time is wasted.</para>
-
-<para>Binutils installs its assembler and linker into two locations,
-<filename class="directory">/tools/bin</filename> and
-<filename class="directory">/tools/$TARGET_TRIPLET/bin</filename>. In reality,
-the tools in one location are hard linked to the other. An important facet of
-the linker is its library search order. Detailed information can be obtained
-from <command>ld</command> by passing it the <parameter>--verbose</parameter>
-flag. For example: <command>ld --verbose | grep SEARCH</command> will
-show you the current search paths and their order. You can see what files are
-actually linked by <command>ld</command> by compiling a dummy program and
-passing the <parameter>--verbose</parameter> switch to the linker. For example:
-<userinput>gcc dummy.c -Wl,--verbose 2&gt;&amp;1 | grep succeeded</userinput>
-will show you all the files successfully opened during the linking.</para>
-
-<para>The next package installed is GCC and during its run of
-<command>./configure</command> you'll see, for example:</para>
+<para>Binutils is installed first because the
+<command>./configure</command> runs of both GCC and Glibc perform
+various feature tests on the assembler and linker to determine which
+software features to enable or disable. This is more important than
+one might first realize. An incorrectly configured GCC or Glibc can
+result in a subtly broken toolchain, where the impact of such breakage
+might not show up until near the end of the build of a whole
+distribution. A test suite failure will usually alert this error
+before too much additional work is performed.</para>
+
+<para>Binutils installs its assembler and linker in two locations,
+<filename class="directory">/tools/bin</filename> and <filename
+class="directory">/tools/$TARGET_TRIPLET/bin</filename>. The tools in
+one location are hard linked to the other. An important facet of the
+linker is its library search order. Detailed information can be
+obtained from <command>ld</command> by passing it the
+<parameter>--verbose</parameter> flag. For example, an <command>ld
+--verbose | grep SEARCH</command> will illustrate the current search
+paths and their order. It shows what files are linked by
+<command>ld</command> by compiling a dummy program and passing the
+<parameter>--verbose</parameter> switch to the linker. For example,
+<userinput>gcc dummy.c -Wl,--verbose 2&gt;&amp;1 | grep
+succeeded</userinput> will show all the files successfully opened
+during the linking.</para>
+
+<para>The next package installed is GCC. An example of what can be
+seen during its run of <command>./configure</command> is:</para>
 
 <blockquote><screen><computeroutput>checking what assembler to use... /tools/i686-pc-linux-gnu/bin/as
 checking what linker to use... /tools/i686-pc-linux-gnu/bin/ld</computeroutput></screen></blockquote>
 
-<para>This is important for the reasons mentioned above. It also demonstrates
-that GCC's configure script does not search the PATH directories to find which
-tools to use. However, during the actual operation of <command>gcc</command>
-itself, the same search paths are not necessarily used. You can find out which
-standard linker <command>gcc</command> will use by running:
-<userinput>gcc -print-prog-name=ld</userinput>.
-Detailed information can be obtained from <command>gcc</command> by passing
-it the <parameter>-v</parameter> flag while compiling a dummy program. For
-example: <userinput>gcc -v dummy.c</userinput> will show you detailed
-information about the preprocessor, compilation and assembly stages, including
-<command>gcc</command>'s include search paths and their order.</para>
- 
-<para>The next package installed is Glibc. The most important considerations for
-building Glibc are the compiler, binary tools and kernel headers. The compiler
-is generally no problem as Glibc will always use the <command>gcc</command>
-found in a PATH directory. The binary tools and kernel headers can be a little
-more troublesome. Therefore we take no risks and use the available configure
-switches to enforce the correct selections. After the run of
-<command>./configure</command> you can check the contents of the
-<filename>config.make</filename> file in the
-<filename class="directory">glibc-build</filename> directory for all the
-important details. You'll note some interesting items like the use of
-<parameter>CC="gcc -B/tools/bin/"</parameter> to control which binary tools are
-used, and also the use of the <parameter>-nostdinc</parameter> and
-<parameter>-isystem</parameter> flags to control the compiler's include search
-path. These items help to highlight an important aspect of the Glibc package:
-it is very self-sufficient in terms of its build machinery and generally does
-not rely on toolchain defaults.</para>
-
-<para>After the Glibc installation, we make some adjustments to ensure that
-searching and linking take place only within our <filename class="directory">/tools</filename>
-prefix. We install an adjusted <command>ld</command>, which has a hard-wired
-search path limited to <filename class="directory">/tools/lib</filename>. Then
-we amend <command>gcc</command>'s specs file to point to our new dynamic
-linker in <filename class="directory">/tools/lib</filename>. This last step is
-<emphasis>vital</emphasis> to the whole process. As mentioned above, a
-hard-wired path to a dynamic linker is embedded into every ELF shared
-executable. You can inspect this by running:
-<userinput>readelf -l &lt;name of binary&gt; | grep interpreter</userinput>.
-By amending <command>gcc</command>'s specs file, we are ensuring that every
-program compiled from here through the end of this chapter will use our new
-dynamic linker in <filename class="directory">/tools/lib</filename>.</para>
-
-<para>The need to use the new dynamic linker is also the reason why we apply the
-Specs patch for the second pass of GCC. Failure to do so will result in the GCC
-programs themselves having the name of the dynamic linker from the host system's
-<filename class="directory">/lib</filename> directory embedded into them, which
-would defeat our goal of getting away from the host.</para>
+<para>This is important for the reasons mentioned above. It also
+demonstrates that GCC's configure script does not search the PATH
+directories to find which tools to use. However, during the actual
+operation of <command>gcc</command> itself, the same
+search paths are not necessarily used. To find out which standard
+linker <command>gcc</command> will use, run: <userinput>gcc
+-print-prog-name=ld</userinput>. Detailed
+information can be obtained from <command>gcc</command> by passing it
+the <parameter>-v</parameter> command line option while compiling a
+dummy program. For example, <userinput>gcc -v dummy.c</userinput> will show detailed
+information about the preprocessor, compilation, and assembly stages,
+including <command>gcc</command>'s included search paths and their
+order.</para>
+
+<para>The next package installed is Glibc. The most important
+considerations for building Glibc are the compiler, binary tools, and
+kernel headers. The compiler is generally not an issue since Glibc
+will always use the <command>gcc</command> found in a PATH directory.
+The binary tools and kernel headers can be a bit more complicated.
+Therefore, take no risks and use the available configure switches to
+enforce the correct selections. After the run of
+<command>./configure</command>, check the contents of the
+<filename>config.make</filename> file in the <filename
+class="directory">glibc-build</filename> directory for all important
+details. Note the use of <parameter>CC="gcc -B/tools/bin/"</parameter>
+to control which binary tools are used and the use of the
+<parameter>-nostdinc</parameter> and <parameter>-isystem</parameter>
+flags to control the compiler's include search path. These items
+highlight an important aspect of the Glibc package -- it is very
+self-sufficient in terms of its build machinery and generally does not
+rely on toolchain defaults.</para>
+
+<para>After the Glibc installation, make some adjustments to ensure
+that searching and linking take place only within the <filename
+class="directory">/tools</filename> prefix.  Install an adjusted
+<command>ld</command>, which has a hard-wired search path limited to
+<filename class="directory">/tools/lib</filename>. Then amend
+<command>gcc</command>'s specs file to point to the new dynamic linker
+in <filename class="directory">/tools/lib</filename>. This last step
+is vital to the whole process. As mentioned above, a hard-wired path
+to a dynamic linker is embedded into every Executable and Link Format
+(ELF)-shared executable.  This can be inspected by running:
+<userinput>readelf -l &lt;name of binary&gt; | grep
+interpreter</userinput>. Amending <command>gcc</command>'s specs file
+ensures that every program compiled from here through the end of this
+chapter will use the new dynamic linker in <filename
+class="directory">/tools/lib</filename>.</para>
+
+<para>The need to use the new dynamic linker is also the reason why
+the Specs patch is applied for the second pass of GCC. Failure to do
+so will result in the GCC programs themselves having the name of the
+dynamic linker from the host system's <filename
+class="directory">/lib</filename> directory embedded into them, which
+would defeat the goal of getting away from the host.</para> 
 
 <para>During the second pass of Binutils, we are able to utilize the
 <parameter>--with-lib-path</parameter> configure switch to control
-<command>ld</command>'s library search path. From this point onwards, the
-core toolchain is self-contained and self-hosted. The remainder of the
-<xref linkend="chapter-temporary-tools"/> packages all build against the new Glibc in
-<filename class="directory">/tools</filename> and all is well.</para>
-
-<para>Upon entering the chroot environment in <xref linkend="chapter-building-system"/>, the
-first major package we install is Glibc, due to its self-sufficient nature that
-we mentioned above. Once this Glibc is installed into
-<filename class="directory">/usr</filename>, we perform a quick changeover of
-the toolchain defaults, then proceed for real in building the rest of the
-target LFS system.</para>
+<command>ld</command>'s library search path.  From this point onwards,
+the core toolchain is self-contained and self-hosted. The remainder of
+the <xref linkend="chapter-temporary-tools"/> packages all build
+against the new Glibc in <filename
+class="directory">/tools</filename>.</para>
+
+<para>Upon entering the chroot environment in <xref
+linkend="chapter-building-system"/>, the first major package to be
+installed is Glibc, due to its self-sufficient nature that we
+mentioned above. Once this Glibc is installed into <filename
+class="directory">/usr</filename>, perform a quick changeover of the
+toolchain defaults, then proceed in building the rest of the target
+LFS system.</para>
 
 <sect2>
 <title>Notes on static linking</title>
 
-<para>Most programs have to perform, beside their specific task, many rather
-common and sometimes trivial operations. These include allocating memory,
-searching directories, reading and writing files, string handling, pattern
-matching, arithmetic and many other tasks. Instead of obliging each program to
-reinvent the wheel, the GNU system provides all these basic functions in
-ready-made libraries. The major library on any Linux system is
-<emphasis>Glibc</emphasis>.</para>
-
-<para>There are two primary ways of linking the functions from a library to a
-program that uses them: statically or dynamically. When a program is linked
-statically, the code of the used functions is included in the executable,
-resulting in a rather bulky program. When a program is dynamically linked, what
-is included is a reference to the dynamic linker, the name of the library, and
-the name of the function, resulting in a much smaller executable. (A third way
-is to use the programming interface of the dynamic linker. See the
-<emphasis>dlopen</emphasis> man page for more information.)</para>
-
-<para>Dynamic linking is the default on Linux and has three major advantages
-over static linking. First, you need only one copy of the executable library
-code on your hard disk, instead of having many copies of the same code included
-into a whole bunch of programs -- thus saving disk space. Second, when several
-programs use the same library function at the same time, only one copy of the
-function's code is required in core -- thus saving memory space. Third, when a
-library function gets a bug fixed or is otherwise improved, you only need to
-recompile this one library, instead of having to recompile all the programs that
-make use of the improved function.</para>
-
-<para>If dynamic linking has several advantages, why then do we statically link
-the first two packages in this chapter? The reasons are threefold: historical,
-educational, and technical. Historical, because earlier versions of LFS
-statically linked every program in this chapter. Educational, because knowing
-the difference is useful. Technical, because we gain an element of independence
-from the host in doing so, meaning that those programs can be used
-independently of the host system. However, it's worth noting that an overall
-successful LFS build can still be achieved when the first two packages are
-built dynamically.</para>
+<para>Besides their specific task, most programs have to perform many
+common and sometimes trivial operations. These include allocating
+memory, searching directories, reading and writing files, string
+handling, pattern matching, arithmetic, and other tasks. Instead of
+obliging each program to reinvent the wheel, the GNU system provides
+all these basic functions in ready-made libraries. The major library
+on any Linux system is Glibc.</para>
+
+<para>There are two primary ways of linking the functions from a
+library to a program that uses them -- statically or dynamically. When
+a program is linked statically, the code of the used functions is
+included in the executable, resulting in a rather bulky program. When
+a program is dynamically linked, it includes a reference to the
+dynamic linker, the name of the library, and the name of the function,
+resulting in a much smaller executable. A third option is to use the
+programming interface of the dynamic linker (see the
+<emphasis>dlopen</emphasis> man page for more information).</para>
+
+<para>Dynamic linking is the default on Linux and has three major
+advantages over static linking. First, only one copy of the executable
+library code is needed on the hard disk, instead of having multiple
+copies of the same code included into several of programs, thus saving
+disk space. Second, when several programs use the same library
+function at the same time, only one copy of the function's code is
+required in core, thus saving memory space. Third, when a library
+function gets a bug fixed or is otherwise improved, only the one
+library needs to be recompiled instead of recompiling all programs
+that make use of the improved function.</para>
+
+<para>If dynamic linking has several advantages, why then do we
+statically link the first two packages in this chapter? The reasons
+are threefold -- historical, educational, and technical. The
+historical reason is that earlier versions of LFS statically linked
+every program in this chapter. Educationally, knowing the difference
+between static and dynamic linking is useful. The technical benefit is
+a gained element of independence from the host, meaning that those
+programs can be used independently of the host system. However, it is
+worth noting that an overall successful LFS build can still be
+achieved when the first two packages are built dynamically.</para>
 
 </sect2>
 
 </sect1>
+
diff --git a/chapter05/udev.xml b/chapter05/udev.xml
index c79001a59..02ebce01c 100644
--- a/chapter05/udev.xml
+++ b/chapter05/udev.xml
@@ -20,23 +20,22 @@
 <seglistitem><seg>0.2 SBU</seg><seg>5.2 MB</seg></seglistitem>
 </segmentedlist>
 
-<!--
+
 <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="../chapter06/udev.xml" xpointer="xpointer(/sect1/sect2[1]/segmentedlist[2])"/>
- -->
 
 </sect2>
 
 <sect2 role="installation">
 <title>Installation of Udev</title>
 
-<para>The <command>udevstart</command> program hardcodes the path 
-to the <command>udev</command> program in itself, which is bad since we 
-install <command>udev</command> in a non-standard location. Fix this by
-running the following:</para>
+<para>The <command>udevstart</command> program hardcodes the path to
+the <command>udev</command> program in itself, which would cause
+issues since <command>udev</command> was installed in a non-standard
+location. Fix this by running the following:</para>
 
 <screen><userinput>sed -i 's@/sbin/udev@/tools/sbin/udev@g' udevstart.c</userinput></screen>
 
-<para>Also assure that <command>udev</command> knows the correct location to look for its
+<para>Also ensure that <command>udev</command> knows the correct location to look for its
 configuration files:</para>
 
 <screen><userinput>sed -i 's@/etc@/tools/etc@g' etc/udev/udev.conf.in</userinput></screen>
@@ -45,12 +44,12 @@ configuration files:</para>
 
 <screen><userinput>make prefix=/tools etcdir=/tools/etc</userinput></screen>
 
-<para>Install it:</para>
+<para>Install the package:</para>
 
 <screen><userinput>make DESTDIR=/tools udevdir=/dev install</userinput></screen>
 
-<para>Udev's configuration is far from ideal by default, so we install our own
-configuration files here:</para>
+<para>Udev's configuration is far from ideal by default, so install
+LFS specific configuration files here:</para>
 
 <screen><userinput>cp ../udev-config-2.permissions /tools/etc/udev/permissions.d/00-lfs.permissions
 cp ../udev-config-1.rules /tools/etc/udev/rules.d/00-lfs.rules</userinput></screen>
@@ -62,3 +61,4 @@ cp ../udev-config-1.rules /tools/etc/udev/rules.d/00-lfs.rules</userinput></scre
 </sect2>
 
 </sect1>
+
diff --git a/chapter05/util-linux.xml b/chapter05/util-linux.xml
index 7561ddd84..5db50eb27 100644
--- a/chapter05/util-linux.xml
+++ b/chapter05/util-linux.xml
@@ -27,14 +27,14 @@
 <sect2 role="installation">
 <title>Installation of Util-linux</title>
 
-<para>Util-linux has issues with the Linux 2.6 kernel series - fix these issues
-by applying the following patch:</para>
+<para>Util-linux has issues with the Linux 2.6 kernel series. These
+issues can be fixed by applying the following patch:</para>
 
 <screen><userinput>patch -Np1 -i ../util-linux-&util-linux-version;-kernel_headers-1.patch</userinput></screen>
 
-<para>Util-linux doesn't use the freshly installed headers and libraries
-from the <filename class="directory">/tools</filename> directory.  This is fixed by altering the configure
-script:</para>
+<para>Util-linux does not use the freshly installed headers and
+libraries from the <filename class="directory">/tools</filename>
+directory. This is fixed by altering the configure script:</para>
 
 <screen><userinput>sed -i 's@/usr/include@/tools/include@g' configure</userinput></screen>
 
@@ -46,8 +46,8 @@ script:</para>
 
 <screen><userinput>make -C lib</userinput></screen>
 
-<para>Since you'll only need a couple of the utilities contained in
-this package, build just those:</para>
+<para>Since only a couple of the utilities contained in this package
+are needed, build only those:</para>
 
 <screen><userinput>make -C mount mount umount
 make -C text-utils more</userinput></screen>
@@ -62,3 +62,4 @@ make -C text-utils more</userinput></screen>
 <para>The details on this package are found in <xref linkend="contents-utillinux"/>.</para>
 </sect2>
 </sect1>
+