Index: chapter05/gcc-pass2.xml
===================================================================
--- chapter05/gcc-pass2.xml	(revision d9e7e0a5bbfdd531283fe36734b7536f4c692639)
+++ chapter05/gcc-pass2.xml	(revision 6e41459993b150036ad396aa21212c067db312d4)
@@ -20,4 +20,6 @@
 </segmentedlist>
 
+<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="../chapter06/gcc.xml" xpointer="xpointer(/sect1/sect2[1]/segmentedlist[2])"/>
+
 </sect2>
 
@@ -25,12 +27,13 @@
 <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>
@@ -40,42 +43,46 @@
 <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>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>First correct a problem and make an essential adjustment:</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>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 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>
@@ -100,26 +107,28 @@
 <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>
@@ -133,7 +142,7 @@
 <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>
@@ -143,42 +152,46 @@
 <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>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>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 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>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>Having a few unexpected failures often cannot be avoided. The GCC
-developers are usually aware of these, but haven't yet gotten around to fixing
-them. In short, unless your results are vastly different from those at the above
-URL, it is safe to continue.</para>
-
-<para>And finally install the package:</para>
+<para>For only the summaries, pipe the output through
+<userinput>grep -A7 Summ</userinput>.</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 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>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>
@@ -189,2 +202,3 @@
 
 </sect1>
+
