12 files changed, 22 insertions, 561 deletions
diff --git a/chapter05/adjusting.xml b/chapter05/adjusting.xml
index 6d3aca31f..c3d584ab2 100644
--- a/chapter05/adjusting.xml
+++ b/chapter05/adjusting.xml
@@ -22,6 +22,8 @@ unset SPECFILE</userinput></screen>
 
 <screen><userinput>rm -f /tools/lib/gcc/*/*/include/{pthread.h,bits/sigthread.h}</userinput></screen>
 
+<para>Test the tools:</para>
+
 <screen><userinput>echo 'main(){}' &gt; dummy.c
 cc dummy.c
 readelf -l a.out | grep ': /tools'</userinput></screen>
diff --git a/chapter05/gcc-pass1.xml b/chapter05/gcc-pass1.xml
index 9fa5601bb..81f934e04 100644
--- a/chapter05/gcc-pass1.xml
+++ b/chapter05/gcc-pass1.xml
@@ -12,7 +12,6 @@
 <secondary>tools, pass 1</secondary></indexterm>
 
 <sect2 role="package"><title/>
-<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="../chapter06/gcc.xml" xpointer="xpointer(/sect1/sect2[1]/para[1])"/>
 
 <segmentedlist>
 <segtitle>&buildtime;</segtitle>
@@ -20,25 +19,11 @@
 <seglistitem><seg>4.4 SBU</seg><seg>300 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>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>This package is known to behave badly when you change 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 GCC.</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>
 
@@ -49,92 +34,16 @@ cd ../gcc-build</userinput></screen>
     --with-local-prefix=/tools --disable-nls \
     --enable-shared --enable-languages=c</userinput></screen>
 
-<para>The meaning of the configure options:</para>
-
-<variablelist>
-<varlistentry>
-<term><parameter>CC="gcc -B/usr/bin"</parameter></term>
-<listitem><para>This parameter fixes a possible problem with building GCC
-at this stage, first noticed in LFS 5.1.1.  If our host uses a new version
-of Binutils than we compiled, the host compiler may try use features not
-supported by our new linker, causing compilation errors.  By passing the -B
-flag to gcc, we cause the compiler to temporarily use the host's linker,
-which solves the problem.</para></listitem>
-</varlistentry>
-
-<varlistentry>
-<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>
-</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>
-</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>
-</varlistentry>
-</variablelist>
-
 <para>Continue with compiling the package:</para>
 
 <screen><userinput>make BOOT_LDFLAGS="-static" bootstrap</userinput></screen>
 
-<para>The meaning of the make parameters:</para>
-
-<variablelist>
-<varlistentry>
-<term><parameter>BOOT_LDFLAGS="-static"</parameter></term>
-<listitem><para>This tells GCC to link its programs statically.</para></listitem>
-</varlistentry>
-
-<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>
-</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>Now 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>
-
 <screen><userinput>ln -s gcc /tools/bin/cc</userinput></screen>
 
 </sect2>
 
-<sect2 role="content"><title/>
-<para>The details on this package are found in <xref linkend="contents-gcc"/>.</para>
-</sect2>
-
 </sect1>
diff --git a/chapter05/gcc-pass2.xml b/chapter05/gcc-pass2.xml
index 398d43f48..7c3f01d44 100644
--- a/chapter05/gcc-pass2.xml
+++ b/chapter05/gcc-pass2.xml
@@ -24,68 +24,18 @@
 <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>Check if there is PTYs for the test suites:</para>
 
 <screen><userinput>expect -c "spawn ls"</userinput></screen>
 
-<para>The response might be:</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>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>
-
 <screen><userinput>patch -Np1 -i ../gcc-&gcc-version;-no_fixincludes-1.patch
 patch -Np1 -i ../gcc-&gcc-version;-specs-2.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>Create a separate build directory again:</para>
 
 <screen><userinput>mkdir ../gcc-build
 cd ../gcc-build</userinput></screen>
 
-<para>Before starting to build GCC, remember to unset any environment
-variables that override the default optimization flags.</para>
-
 <para>Now prepare GCC for compilation:</para>
 
 <screen><userinput>../gcc-&gcc-version;/configure --prefix=/tools \
@@ -94,83 +44,24 @@ variables that override the default optimization flags.</para>
     --enable-__cxa_atexit --enable-languages=c,c++ \
     --disable-libstdcxx-pch</userinput></screen>
 
-<para>The meaning of the new configure options:</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>
-</varlistentry>
-
-<varlistentry>
-<term><parameter>--enable-threads=posix</parameter></term>
-<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
-distributions.</para></listitem>
-</varlistentry>
-
-<varlistentry>
-<term><parameter>--enable-languages=c,c++</parameter></term>
-<listitem><para>This option
-ensures that both the C and C++ compilers are built.</para></listitem>
-</varlistentry>
-
-<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>
-</varlistentry>
-</variablelist>
-
 <para>Compile the package:</para>
 
 <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>
-
 <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>
+<para>To get a summary of the test suite results, run this:</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
+<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-11/msg00569.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>
 
 <screen><userinput>make install</userinput></screen>
@@ -183,8 +74,4 @@ GCC Specs patch.</para></note>
 
 </sect2>
 
-<sect2 role="content"><title/>
-<para>The details on this package are found in <xref linkend="contents-gcc"/>.</para>
-</sect2>
-
 </sect1>
diff --git a/chapter05/gettext.xml b/chapter05/gettext.xml
index d88a1a358..f430deb5f 100644
--- a/chapter05/gettext.xml
+++ b/chapter05/gettext.xml
@@ -12,7 +12,6 @@
 <secondary>tools</secondary></indexterm>
 
 <sect2 role="package"><title/>
-<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="../chapter06/gettext.xml" xpointer="xpointer(/sect1/sect2[1]/para[1])"/>
 
 <segmentedlist>
 <segtitle>&buildtime;</segtitle>
@@ -20,8 +19,6 @@
 <seglistitem><seg>0.5 SBU</seg><seg>55 MB</seg></seglistitem>
 </segmentedlist>
 
-<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="../chapter06/gettext.xml" xpointer="xpointer(/sect1/sect2[1]/segmentedlist[2])"/>
-
 </sect2>
 
 <sect2 role="installation">
@@ -32,36 +29,12 @@
 <screen><userinput>./configure --prefix=/tools --disable-libasprintf \
     --disable-csharp</userinput></screen>
 
-<para>The meaning of the configure options:</para>
-
-<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>
-</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>
-</varlistentry>
-</variablelist>
-
-<para>Compile the programs:</para>
+<para>Compile the package:</para>
 
 <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></para>
 
 <para>And install the package:</para>
 
@@ -69,8 +42,4 @@ project).)</para>
 
 </sect2>
 
-<sect2 role="content"><title/>
-<para>The details on this package are found in <xref linkend="contents-gettext"/>.</para>
-</sect2>
-
 </sect1>
diff --git a/chapter05/glibc.xml b/chapter05/glibc.xml
index 3b7ac093a..b256792f1 100644
--- a/chapter05/glibc.xml
+++ b/chapter05/glibc.xml
@@ -12,7 +12,6 @@
 <secondary>tools</secondary></indexterm>
 
 <sect2 role="package"><title/>
-<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="../chapter06/glibc.xml" xpointer="xpointer(/sect1/sect2[1]/para[1])"/>
 
 <segmentedlist>
 <segtitle>&buildtime;</segtitle>
@@ -20,25 +19,11 @@
 <seglistitem><seg>11.8 SBU</seg><seg>800 MB</seg></seglistitem>
 </segmentedlist>
 
-<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="../chapter06/glibc.xml" xpointer="xpointer(/sect1/sect2[1]/segmentedlist[2])"/>
-
 </sect2>
 
 <sect2 role="installation">
 <title>Installation of Glibc</title>
 
-<para>This package is known to behave badly when you change 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 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>The Glibc documentation recommends building Glibc outside of the source
-directory in a dedicated build directory:</para>
-
 <screen><userinput>mkdir ../glibc-build
 cd ../glibc-build</userinput></screen>
 
@@ -49,104 +34,15 @@ cd ../glibc-build</userinput></screen>
     --enable-kernel=2.6.0 --with-binutils=/tools/bin \
     --without-gd --without-cvs --with-headers=/tools/include</userinput></screen>
 
-<para>The meaning of the configure options:</para>
-
-<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>
-</varlistentry>
-
-<varlistentry>
-<term><parameter>--enable-add-ons</parameter></term>
-<listitem><para>This tells Glibc to use the add-on' that it can use like NPTL
-as its threading library.</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>
-</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 
-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>
-</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>
-</varlistentry>
-
-<varlistentry>
-<term><parameter>--with-headers=/tools/include</parameter></term>
-<listitem><para>This forces glibc to use the linux-libc-headers installed
-in /tools/include, rather than those on the host, which may be too old to
-support needed functionality.</para></listitem>
-</varlistentry>
-
-</variablelist>
-
-<para>During this stage you might see the following warning:</para>
-
-<blockquote><screen><computeroutput>configure: WARNING:
-*** These auxiliary programs are missing or incompatible versions: msgfmt
-*** some features will be disabled.
-*** 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>
-
 <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>
-
 <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>
-
 <screen><userinput>mkdir /tools/etc
 touch /tools/etc/ld.so.conf</userinput></screen>
 
@@ -154,30 +50,15 @@ touch /tools/etc/ld.so.conf</userinput></screen>
 
 <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>
-
-<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>
-
-<para>If you still want to install the Glibc locales anyway, the following
-command will do so:</para>
+<para>To install the Glibc locales, 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>
+locales which you need or want. 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>
 
 <screen><userinput>mkdir -p /tools/lib/locale
 localedef -i de_DE -f ISO-8859-1 de_DE
@@ -194,8 +75,4 @@ localedef -i ja_JP -f EUC-JP ja_JP</userinput></screen>
 
 </sect2>
 
-<sect2 role="content"><title/>
-<para>The details on this package are found in <xref linkend="contents-glibc"/>.</para>
-</sect2>
-
 </sect1>
diff --git a/chapter05/grep.xml b/chapter05/grep.xml
index 9fcdaca18..c95433cff 100644
--- a/chapter05/grep.xml
+++ b/chapter05/grep.xml
@@ -12,7 +12,6 @@
 <secondary>tools</secondary></indexterm>
 
 <sect2 role="package"><title/>
-<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="../chapter06/grep.xml" xpointer="xpointer(/sect1/sect2[1]/para[1])"/>
 
 <segmentedlist>
 <segtitle>&buildtime;</segtitle>
@@ -20,8 +19,6 @@
 <seglistitem><seg>0.1 SBU</seg><seg>5.8 MB</seg></seglistitem>
 </segmentedlist>
 
-<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="../chapter06/grep.xml" xpointer="xpointer(/sect1/sect2[1]/segmentedlist[2])"/>
-
 </sect2>
 
 <sect2 role="installation">
@@ -32,39 +29,17 @@
 <screen><userinput>./configure --prefix=/tools \
     --disable-perl-regexp --with-included-regex</userinput></screen>
 
-<para>The meaning of the configure options:</para>
-
-<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>
-</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>
-</varlistentry>
-</variablelist>
-
-<para>Compile the programs:</para>
+<para>Compile the package:</para>
 
 <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>
 
 </sect2>
 
-<sect2 role="content"><title/>
-<para>The details on this package are found in <xref linkend="contents-grep"/>.</para>
-</sect2>
-
 </sect1>
diff --git a/chapter05/gzip.xml b/chapter05/gzip.xml
index 045648cf4..da725178b 100644
--- a/chapter05/gzip.xml
+++ b/chapter05/gzip.xml
@@ -12,7 +12,6 @@
 <secondary>tools</secondary></indexterm>
 
 <sect2 role="package"><title/>
-<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="../chapter06/gzip.xml" xpointer="xpointer(/sect1/sect2[1]/para[1])"/>
 
 <segmentedlist>
 <segtitle>&buildtime;</segtitle>
@@ -20,8 +19,6 @@
 <seglistitem><seg>0.1 SBU</seg><seg>2.6 MB</seg></seglistitem>
 </segmentedlist>
 
-<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="../chapter06/gzip.xml" xpointer="xpointer(/sect1/sect2[1]/segmentedlist[2])"/>
-
 </sect2>
 
 <sect2 role="installation">
@@ -41,8 +38,4 @@
 
 </sect2>
 
-<sect2 role="content"><title/>
-<para>The details on this package are found in <xref linkend="contents-gzip"/>.</para>
-</sect2>
-
 </sect1>
diff --git a/chapter05/hostreqs.xml b/chapter05/hostreqs.xml
index fb34e8db7..119d796a3 100644
--- a/chapter05/hostreqs.xml
+++ b/chapter05/hostreqs.xml
@@ -7,31 +7,6 @@
 <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>
-
-<screen><userinput>cat /proc/version</userinput></screen>
-
-<para>This will produce output similar to:</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>See testing.</para>
 
 </sect1>
diff --git a/chapter05/introduction.xml b/chapter05/introduction.xml
index 78c883ecd..eaf2f7b2c 100644
--- a/chapter05/introduction.xml
+++ b/chapter05/introduction.xml
@@ -7,58 +7,6 @@
 <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>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>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>
-
-<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>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>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>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>Now first check that your 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>See testing.</para>
 
 </sect1>
diff --git a/chapter05/kernel-headers.xml b/chapter05/kernel-headers.xml
deleted file mode 100644
index d18ac0020..000000000
--- a/chapter05/kernel-headers.xml
+++ /dev/null
@@ -1,61 +0,0 @@
-<?xml version="1.0" encoding="ISO-8859-1"?>
-<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN" "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [
-  <!ENTITY % general-entities SYSTEM "../general.ent">
-  %general-entities;
-]>
-<sect1 id="ch-tools-kernel-headers" role="wrap">
-<title>Linux-&linux-version; headers</title>
-<?dbhtml filename="kernel-headers.html"?>
-
-<indexterm zone="ch-tools-kernel-headers">
-<primary sortas="a-Linux">Linux</primary>
-<secondary>tools, headers</secondary></indexterm>
-
-<sect2 role="package"><title/>
-
-<segmentedlist>
-<segtitle>&buildtime;</segtitle>
-<segtitle>&diskspace;</segtitle>
-<seglistitem><seg>0.1 SBU</seg><seg>186 MB</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>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>Create the <filename>include/linux/version.h</filename> file:</para>
-
-<screen><userinput>make include/linux/version.h</userinput></screen>
-
-<para>Create the platform-specific <filename class="symlink">include/asm</filename>
-symlink:</para>
-
-<screen><userinput>make include/asm</userinput></screen>
-
-<para>Install the platform-specific header files:</para>
-
-<screen><userinput>mkdir /tools/glibc-kernheaders
-cp -HR include/asm /tools/glibc-kernheaders
-cp -R include/asm-generic /tools/glibc-kernheaders</userinput></screen>
-
-<para>Finally, install the cross-platform kernel header files:</para>
-
-<screen><userinput>cp -R include/linux /tools/glibc-kernheaders</userinput></screen>
-
-</sect2>
-
-</sect1>
diff --git a/chapter05/linux-libc-headers.xml b/chapter05/linux-libc-headers.xml
index a74ce26e3..bfbc637f3 100644
--- a/chapter05/linux-libc-headers.xml
+++ b/chapter05/linux-libc-headers.xml
@@ -24,12 +24,6 @@
 <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>Install the header files:</para>
 
 <screen><userinput>cp -R include/asm-i386 /tools/include/asm
diff --git a/chapter05/m4.xml b/chapter05/m4.xml
index 5907e5cfc..0a4757497 100644
--- a/chapter05/m4.xml
+++ b/chapter05/m4.xml
@@ -12,7 +12,6 @@
 <secondary>tools</secondary></indexterm>
 
 <sect2 role="package"><title/>
-<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="../chapter06/m4.xml" xpointer="xpointer(/sect1/sect2[1]/para[1])"/>
 
 <segmentedlist>
 <segtitle>&buildtime;</segtitle>
@@ -20,8 +19,6 @@
 <seglistitem><seg>0.1 SBU</seg><seg>3.0 MB</seg></seglistitem>
 </segmentedlist>
 
-<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="../chapter06/m4.xml" xpointer="xpointer(/sect1/sect2[1]/segmentedlist[2])"/>
-
 </sect2>
 
 <sect2 role="installation">
@@ -44,8 +41,4 @@
 
 </sect2>
 
-<sect2 role="content"><title/>
-<para>The details on this package are found in <xref linkend="contents-m4"/>.</para>
-</sect2>
-
 </sect1>