Minor textual shuffles.

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

chapter01/changelog.xml

@@ -17,7 +17,21 @@ first a summary, then a detailed log.</para>
 <listitem><para>less-382</para></listitem>
 <listitem><para>man-pages-1.66</para></listitem>
 <listitem><para>ncurses-5.4</para></listitem>
-</itemizedlist></listitem>
+</itemizedlist>
+</listitem>
+
+<listitem><para>Added:</para>
+<itemizedlist>
+<listitem><para>make_devices-1.2</para></listitem>
+</itemizedlist>
+</listitem>
+ 
+<listitem><para>Removed:</para>
+<itemizedlist>
+<listitem><para>MAKEDEV-1.7</para></listitem>
+<listitem><para>ncurses-5.3-etip-2.patch</para></listitem>
+</itemizedlist>
+</listitem>
 
 <listitem><para>February 23rd, 2004 [alex]: Chapters 6 + 9 : Cleaned up the
 Revision of chroot and Reboot sections.</para></listitem>

chapter05/binutils-pass1.xml

@@ -17,11 +17,11 @@
 because both Glibc and GCC perform various tests on the available linker and
 assembler to determine which of their own features to enable.</para>
 
-<para>This package is known to behave badly when you have changed its default
+<para>This package is known to behave badly when you change its default
-optimization flags (including the -march and -mcpu options). Therefore, if
+optimization flags (including the <emphasis>-march</emphasis> and
-you have defined any environment variables that override default
+<emphasis>-mcpu</emphasis> options). Therefore, if you have defined any
-optimizations, such as CFLAGS and CXXFLAGS, we recommend unsetting or
+environment variables that override default optimizations, such as CFLAGS and
-modifying them when building Binutils.</para>
+CXXFLAGS, we recommend unsetting them when building Binutils.</para>
 
 <para>The Binutils documentation recommends building Binutils outside of the
 source directory in a dedicated build directory:</para>
@@ -30,9 +30,11 @@ source directory in a dedicated build directory:</para>
 cd ../binutils-build</userinput></screen>
 
 <note><para>If you want the SBU values listed in the rest of the book to be of
-any use, you will have to measure the time it takes to build this package. To
+any use, you will have to measure the time it takes to build this package --
-achieve this easily, you could do something like:
+from the configuration upto and including the first install. To achieve this
-<userinput>time { ./configure ... &amp;&amp; ... &amp;&amp; ... &amp;&amp; make install; }</userinput>.</para></note>
+easily, you could wrap the four commands in a <command>time</command> command
+like this: <userinput>time { ./configure ... &amp;&amp; ... &amp;&amp; ...
+&amp;&amp; make install; }</userinput>.</para></note>
 
 <para>Now prepare Binutils for compilation:</para>
 
@@ -66,18 +68,16 @@ problem.</para></listitem>
 
 <listitem><para><userinput>LDFLAGS="-all-static"</userinput>: This tells the
 linker that all the Binutils programs should be linked statically. However,
-strictly speaking, <emphasis>"-all-static"</emphasis> is first passed to the
+strictly speaking, <emphasis>"-all-static"</emphasis> is passed to the
-<command>libtool</command> program which then passes
+<command>libtool</command> program, which then passes
-<emphasis>"-static"</emphasis> on to the linker.</para></listitem>
+<emphasis>"-static"</emphasis> to the linker.</para></listitem>
 </itemizedlist>
 
-<para>Compilation is now complete. This is the point where we would normally
+<para>Compilation is complete. Normally we would now run the test suite, but
-run the test suite. But as discussed earlier, we don't recommend running the
+at this early stage the test suite framework (Tcl, Expect and DejaGnu) is not
-test suites for the temporary tools here in this chapter. However, even if we
+yet in place. And there would be little point in running the tests anyhow,
-still wanted to run the Binutils test suite, we're unable do so at this early
+since the programs from this first pass will soon be replaced by those from the
-stage because the test suite framework is not yet in place. Not only that, the
+second.</para>
-programs from this first pass will soon be overwritten by those installed in
-the second pass.</para>
 
 <para>And install the package:</para>
 
@@ -92,16 +92,16 @@ make -C ld LDFLAGS="-all-static" LIB_PATH=/tools/lib</userinput></screen>
 
 <itemizedlist>
 <listitem><para><userinput>-C ld clean</userinput>: This tells the make program
-to remove all the compiled files, but only in the <filename>ld</filename>
+to remove all the compiled files in the <filename
-subdirectory.</para></listitem>
+class="directory">ld</filename> subdirectory.</para></listitem>
 
-<listitem><para><userinput>-C ld LDFLAGS="-all-static" LIB_PATH=/tools/lib</userinput>:
+<listitem><para><userinput>-C ld LDFLAGS="-all-static"
-This option rebuilds everything in the <filename>ld</filename> subdirectory.
+LIB_PATH=/tools/lib</userinput>: This option rebuilds everything in the
-Specifying the LIB_PATH makefile variable on the command line allows us to
+<filename class="directory">ld</filename> subdirectory. Specifying the LIB_PATH
-override the default value and have it point to our temporary tools location.
+makefile variable on the command line allows us to override the default value
-The value of this variable specifies the linker's default library search path.
+and have it point to our temporary tools location. The value of this variable
-You'll see how this preparation is used later on in the
+specifies the linker's default library search path. You will see how this
-chapter.</para></listitem>
+preparation is used later on in the chapter.</para></listitem>
 </itemizedlist>
 
 <!-- HACK - Force some whitespace to appease tidy -->

chapter05/binutils-pass2.xml

@@ -8,7 +8,6 @@
 &aa-binutils-down;
 &aa-binutils-dep;
 
-
 <sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
 
 <sect2>
@@ -28,9 +27,10 @@ cd ../binutils-build</userinput></screen>
 
 <itemizedlist>
 <listitem><para><userinput>--with-lib-path=/tools/lib</userinput>: This tells
-the configure script to specify the default library search path. We don't want
+the configure script to specify the library search path during the compilation
-the library search path to contain library directories from the host
+of Binutils, resulting in <emphasis>/tools/lib</emphasis> to be passed to the
-system.</para></listitem>
+linker. This prevents the linker from searching through library directories on
+the host.</para></listitem>
 </itemizedlist>
 
 <para>Before starting to build Binutils, remember to unset any environment
@@ -41,16 +41,16 @@ variables that override the default optimization flags.</para>
 <screen><userinput>make</userinput></screen>
 
 <para>Compilation is now complete. As discussed earlier, we don't recommend
-running the test suites for the temporary tools here in this chapter. If you
+running the test suites for the temporary tools here in this chapter. If
-still want to run the Binutils test suite anyway, the following command will
+nevertheless you want to run the Binutils test suite, the following command
-do so:</para>
+will do so:</para>
 
 <screen><userinput>make check</userinput></screen>
 
 <para>There should be no unexpected failures here, expected failures are fine.
-Unfortunately, there is no easy way to view the test results summary like
+Unfortunately, there is no easy way to view the test results summary like there
-there was for the previous GCC package. However, if a failure occurs here, it
+was for the GCC package. However, if a failure occurs here, it should be easy
-should be easy to spot. The output shown will contain something like:</para>
+to spot. The output shown will contain something like:</para>
 
 <blockquote><screen>make[1]: *** [check-binutils] Error 2</screen></blockquote>
 

chapter05/chapter05.xml

@@ -512,13 +512,15 @@ cc dummy.c
 readelf -l a.out | grep ': /tools'</userinput></screen>
 
 <para>If everything is working correctly, there should be no errors, and the
-output of the last command will be:</para>
+output of the last command will be (allowing for platform specific differences
+in dynamic linker name):</para>
 
 <blockquote><screen>[Requesting program interpreter: /tools/lib/ld-linux.so.2]</screen></blockquote>
 
-<para>(Of course allowing for platform specific differences in dynamic linker
+<para>Note especially that <filename class="directory">/tools/lib</filename>
-name). Note especially that <filename class="directory">/tools/lib</filename>
+appears as the prefix of our dynamic linker.</para>
-appears as the prefix of our dynamic linker. If you did not receive the output
+
+<para>If you did not receive the output
 as shown above, or received no output at all, then something is seriously wrong.
 You will need to investigate and retrace your steps to find out where the
 problem is and correct it. There is no point in continuing until this is done.

chapter05/coreutils.xml

@@ -17,16 +17,16 @@ And for the patch:
 <sect2>
 <title>Installation of Coreutils</title>
 
-<para>Coreutils has an issue when compiled against Glibc-&glibc-version;.
+<para>This package has an issue when compiled against Glibc-&glibc-version;.
-Without the patch below, some of the Coreutils utilities
+Without the patch below, some of the Coreutils utilities (such as
-(<command>head</command>, <command>tail</command>, <command>sort</command>,
+(<command>head</command>, <command>tail</command> and <command>sort</command>)
-and others) will reject their traditional syntax which has been in use for
+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.
+should be preserved until the many places where it is used can be updated. More
-More details on this are provided in the comments inside the patch itself. Use
+details on this are provided in the comments inside the patch itself. Use of
-of this patch is by no means compulsory, but not using it means you'll have to
+this patch is by no means compulsory, but not using it means you'll have to
-deal with the consequences yourself: patch the many packages that use the old
+deal with the consequences yourself: patch the many packages that still use the
-syntax. Therefore, better apply the patch:</para>
+old syntax. Therefore, better apply the patch:</para>
 
 <screen><userinput>patch -Np1 -i ../&coreutils-posixver-patch;</userinput></screen>
 

chapter05/expect.xml

@@ -16,13 +16,11 @@ other interactive programs.</para>
 <sect2>
 <title>Installation of Expect</title>
 
-<para>First apply a patch:</para>
+<para>First fix a bug that can result in bogus failures during the GCC test
+suite run:</para>
 
 <screen><userinput>patch -Np1 -i ../&expect-patch;</userinput></screen>
 
-<para>This fixes a bug in Expect that can result in bogus failures during the
-GCC test suite run.</para>
-
 <para>Now prepare Expect for compilation:</para>
 
 <screen><userinput>./configure --prefix=/tools --with-tcl=/tools/lib --with-x=no</userinput></screen>
@@ -57,8 +55,8 @@ considered critical.)</para>
 <para>The meaning of the make parameter:</para>
 
 <itemizedlist>
-<listitem><para><userinput>SCRIPTS=""</userinput>: This prevents installation of
+<listitem><para><userinput>SCRIPTS=""</userinput>: This prevents installation
-the supplementary expect scripts which are not needed.</para></listitem>
+of the supplementary expect scripts which are not needed.</para></listitem>
 </itemizedlist>
 
 <para>You can now remove the source directories of both Tcl and Expect.</para>

chapter05/gcc-pass1.xml

@@ -15,14 +15,14 @@
 <sect2>
 <title>Installation of GCC</title>
 
-<para>Unpack only the GCC-core tarball, as we won't be needing a C++ compiler
+<para>Unpack only the GCC-core tarball, as we won't be needing the C++ compiler
-for the moment.</para>
+nor the test suite at the moment.</para>
 
-<para>This package is known to behave badly when you have changed its
+<para>This package is known to behave badly when you change its default
-default optimization flags (including the -march and -mcpu options).
+optimization flags (including the <emphasis>-march</emphasis> and
-Therefore, if you have defined any environment variables that override
+<emphasis>-mcpu</emphasis> options). Therefore, if you have defined any
-default optimizations, such as CFLAGS and CXXFLAGS, we recommend unsetting
+environment variables that override default optimizations, such as CFLAGS and
-or modifying them when building GCC.</para>
+CXXFLAGS, we recommend unsetting them when building GCC.</para>
 
 <para>The GCC documentation recommends building GCC outside of the source
 directory in a dedicated build directory:</para>
@@ -52,8 +52,8 @@ seem counter-intuitive at first. But using it allows the building of
 having <filename>libgcc_eh.a</filename> available ensures that the configure
 script for Glibc (the next package we compile) produces the proper results.
 Note that the <command>gcc</command> binaries will still be linked
-statically, as this is controlled by the <command>-static</command>
+statically, as this is controlled by the <emphasis>-static</emphasis>
-value of BOOT_LDFLAGS further on.</para></listitem>
+value of BOOT_LDFLAGS in the next step.</para></listitem>
 
 <listitem><para><userinput>--enable-languages=c</userinput>: This option
 ensures that only the C compiler is built. The option is only needed when you
@@ -78,21 +78,17 @@ reproduce itself flawlessly, which most probably means that it was
 compiled correctly.</para></listitem>
 </itemizedlist>
 
-<para>Compilation is now complete. This is the point where we would normally
+<para>Compilation is now complete, and at this point we would normally run the
-run the test suite. But as discussed earlier, we don't recommend running the
+test suite. But, as mentioned before, the test suite framework is not in place
-test suites for the temporary tools here in this chapter. However, even if we
+yet. And there would be little point in running the tests anyhow, since the
-still wanted to run the GCC test suite, we're unable do so at this early stage
+programs from this first pass will soon be replaced.</para>
-because the test suite framework is not yet in place. Not only that, the
-programs from this first pass will soon be overwritten by those installed in
-the second pass.</para>
 
 <para>And install the package:</para>
 
 <screen><userinput>make install</userinput></screen>
 
-<para>As a finishing touch we'll create the <filename
+<para>As a finishing touch we'll create a symlink. Many programs and scripts
-class="symlink">/tools/bin/cc</filename> symlink. Many programs and
+run <command>cc</command> instead of <command>gcc</command>,
-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

chapter05/gcc-pass2.xml

@@ -13,33 +13,33 @@
 <sect2>
 <title>Re-installation of GCC</title>
 
-<para>The tools required to test GCC and Binutils are installed now (Tcl, Expect
+<para>The tools required to test GCC and Binutils are installed now: Tcl,
-and DejaGnu). We can continue on rebuilding GCC and Binutils, link them against
+Expect and DejaGnu. Therefore we can now rebuild GCC and Binutils, linking
-the new Glibc, and test them properly (if performing the test suites in this
+them against the new Glibc, and test them properly (if running the test suites
-chapter). One thing to note, however, is that these test suites are highly
+in this chapter). One thing to note, however, is that these test suites are
-dependent on properly functioning pseudo terminals (PTYs) which are provided by
+highly dependent on properly functioning pseudo terminals (PTYs) which are
-your host distribution. These days, PTYs are most commonly implemented via the
+provided by your host. These days, PTYs are most commonly implemented via the
 <emphasis>devpts</emphasis> file system. You can quickly check if your host
 system is set up correctly in this regard by performing a simple test:</para>
 
 <screen><userinput>expect -c "spawn ls"</userinput></screen>
 
-<para>If you receive the message:</para>
+<para>The response might be:</para>
 
 <blockquote><screen>The system has no more ptys.  Ask your system administrator to create more.</screen></blockquote>
 
-<para>Your host distribution is not set up for proper PTY operation. In this
+<para>If you receive the above message, your host doesn't have its PTYs set up
-case there is no point in running the test suites for GCC and Binutils until
+properly. In this case there is no point in running the test suites for GCC
-you are able to resolve the issue. You can consult the LFS Wiki at
+and Binutils until you are able to resolve the issue. You can consult the LFS
-<ulink url="&wiki-root;"/> for more information on how to get PTYs
+Wiki at <ulink url="&wiki-root;"/> for more information on how to get PTYs
 working.</para>
 
 <para>This time we will build both the C and the C++ compilers, so you'll have
-to unpack all three GCC tarballs (-core, -g++, and -testsuite) in one and the
+to unpack both the core and the g++ tarballs (and testsuite too, if you want to
-same working directory. They will all unfold into a single
+run the tests). Unpacking them in your working directory, they will all unfold
-<filename>&gcc-dir;/</filename> subdirectory.</para>
+into a single <filename>&gcc-dir;/</filename> subdirectory.</para>
 
-<para>First correct one problem and make an essential adjustment:</para>
+<para>First correct a problem and make an essential adjustment:</para>
 
 <screen><userinput>patch -Np1 -i ../&gcc-nofixincludes-patch;
 patch -Np1 -i ../&gcc-specs-patch;</userinput></screen>
@@ -56,7 +56,7 @@ directory, resulting in GCC finding the fixed headers from the host system,
 which would most likely not match the Glibc version actually used for the LFS
 system.</para>
 
-<para>The last patch changes GCC's default location of the dynamic linker
+<para>The second patch changes GCC's default location of the dynamic linker
 (typically <filename>ld-linux.so.2</filename>). It also removes
 <filename class="directory">/usr/include</filename> from GCC's include search
 path. Patching now rather than adjusting the specs file after installation
@@ -86,6 +86,14 @@ variables that override the default optimization flags.</para>
 <para>The meaning of the new configure options:</para>
 
 <itemizedlist>
+<listitem><para><userinput>--enable-clocale=gnu</userinput>: This option
+ensures the correct locale model is selected for the C++ libraries under all
+circumstances. If the configure script finds the <emphasis>de_DE</emphasis>
+locale installed, it will select the correct <emphasis>gnu</emphasis> locale
+model. However, people who don't install the <emphasis>de_DE</emphasis> locale
+would run the risk of building ABI incompatible C++ libraries due to the wrong
+<emphasis>generic</emphasis> locale model being selected.</para></listitem>
+
 <listitem><para><userinput>--enable-threads=posix</userinput>: This enables
 C++ exception handling for multi-threaded code.</para></listitem>
 
@@ -96,16 +104,8 @@ handling of destructors. It also affects the C++ ABI and therefore results in
 C++ shared libraries and C++ programs that are interoperable with other Linux
 distributions.</para></listitem>
 
-<listitem><para><userinput>--enable-clocale=gnu</userinput>: This option ensures
+<listitem><para><userinput>--enable-languages=c,c++</userinput>: This option
-the correct locale model is selected for the C++ libraries under all
+ensures that both the C and C++ compilers are built.</para></listitem>
-circumstances. If the configure script finds the <emphasis>de_DE</emphasis>
-locale installed, it will select the correct model of <emphasis>gnu</emphasis>.
-However, people who don't install the <emphasis>de_DE</emphasis> locale, run the
-risk of building ABI incompatible C++ libraries due to the wrong locale model of
-<emphasis>generic</emphasis> being selected.</para></listitem>
-
-<listitem><para><userinput>--enable-languages=c,c++</userinput>: This option is
-needed to ensure that both C and C++ compilers are built.</para></listitem>
 </itemizedlist>
 
 <para>Compile the package:</para>
@@ -116,7 +116,7 @@ needed to ensure that both C and C++ compilers are built.</para></listitem>
 as the compiler we're using to compile this GCC was built from the exact same
 version of the GCC sources we used earlier.</para>
 
-<para>Compilation is now complete. As discussed earlier, we don't recommend
+<para>Compilation is now complete. As mentioned earlier, we don't recommend
 running the test suites for the temporary tools here in this chapter. If you
 still want to run the GCC test suite anyway, the following command will do
 so:</para>
@@ -150,17 +150,18 @@ supported by GCC have support for "__cxa_atexit" in their C libraries, so this
 test is not always expected to pass.</para>
 
 <para>The 24 unexpected passes for libstdc++ are due to the use of
-<emphasis>--enable-clocale=gnu</emphasis>, which is the correct choice on
+<emphasis>--enable-clocale=gnu</emphasis>. This option, which is the correct
-Glibc-based systems of versions 2.2.5 and above. The underlying locale support
+choice on Glibc-based systems of versions 2.2.5 and above, enables in the GNU C
-in the GNU C library is superior to that of the otherwise selected "generic"
+library a locale support that is superior to the otherwise selected
-model (which may be applicable if for instance you were using Newlibc, Sun-libc
+<emphasis>generic</emphasis> model (which may be applicable if for instance you
-or whatever libc). The libstdc++ test suite is apparently expecting the
+were using Newlibc, Sun-libc or whatever other libc). The libstdc++ test suite
-"generic" model, hence those tests are not always expected to pass.</para>
+is apparently expecting the <emphasis>generic</emphasis> model, hence those
+tests are not always expected to pass.</para>
 
-<para>Unexpected failures often cannot be avoided. The GCC developers are
+<para>Having a few unexpected failures often cannot be avoided. The GCC
-usually aware of them but haven't yet gotten around to fixing them. In short,
+developers are usually aware of these, but haven't yet gotten around to fixing
-unless your results are vastly different from those at the above URL, it is safe
+them. In short, unless your results are vastly different from those at the
-to continue on.</para>
+above URL, it is safe to continue.</para>
 
 <para>And finally install the package:</para>
 
@@ -168,9 +169,9 @@ to continue on.</para>
 
 <note><para>At this point it is strongly recommended to repeat the sanity check
 we performed earlier in this chapter. Refer back to
-<xref linkend="ch-tools-adjusting"/> and repeat the check. If the results are
+<xref linkend="ch-tools-adjusting"/> and repeat the little test compilation. If
-wrong, then most likely you forgot to apply the above mentioned GCC Specs
+the result is wrong, then most likely you forgot to apply the above mentioned
-patch.</para></note>
+GCC Specs patch.</para></note>
 
 </sect2>
 

chapter05/glibc.xml

@@ -13,11 +13,11 @@
 <sect2>
 <title>Installation of Glibc</title>
 
-<para>This package is known to behave badly when you have changed its
+<para>This package is known to behave badly when you change its default
-default optimization flags (including the -march and -mcpu options).
+optimization flags (including the <emphasis>-march</emphasis> and
-Therefore, if you have defined any environment variables that override
+<emphasis>-mcpu</emphasis> options). Therefore, if you have defined any
-default optimizations, such as CFLAGS and CXXFLAGS, we recommend unsetting
+environment variables that override default optimizations, such as CFLAGS and
-them when building Glibc.</para>
+CXXFLAGS, we recommend unsetting them when building Glibc.</para>
 
 <para>Basically, compiling Glibc in any other way than the book suggests
 is putting the stability of your system at risk.</para>
@@ -40,7 +40,7 @@ cd ../glibc-build</userinput></screen>
 <itemizedlist>
 <listitem><para><userinput>--disable-profile</userinput>: This disables the
 building of the libraries with profiling information. Omit this option if you
-plan to do profiling.</para></listitem>
+plan to do profiling on the temporary tools.</para></listitem>
 
 <listitem><para><userinput>--enable-add-ons=linuxthreads</userinput>: This
 tells Glibc to use the Linuxthreads add-on as its threading
@@ -71,7 +71,7 @@ suppresses an annoying but harmless warning about a missing
 *** some features will be disabled.
 *** Check the INSTALL file for required versions.</screen></blockquote>
 
-<para>The missing or incompatible <filename>msgfmt</filename> program is
+<para>The missing or incompatible <command>msgfmt</command> program is
 generally harmless, but it's believed it can sometimes cause problems when
 running the test suite.</para>
 
@@ -79,7 +79,7 @@ running the test suite.</para>
 
 <screen><userinput>make</userinput></screen>
 
-<para>Compilation is now complete. As discussed earlier, we don't recommend
+<para>Compilation is now complete. As mentioned earlier, we don't recommend
 running the test suites for the temporary system here in this chapter. If you
 still want to run the Glibc test suite anyway, the following command will do
 so:</para>
@@ -90,10 +90,10 @@ so:</para>
 system, in particular the kernel. Additionally, here in this chapter some tests
 can be adversely affected by existing tools or environmental issues on the host
 system. Of course, these won't be a problem when we run the Glibc test suite
-inside the chroot environment of <xref linkend="chapter-building-system"/>. In general, the
+inside the chroot environment of <xref linkend="chapter-building-system"/>. In
-Glibc test suite is always expected to pass. However, as mentioned above, some
+general, the Glibc test suite is always expected to pass. However, as mentioned
-failures are unavoidable in certain circumstances. Here is a list of the most
+above, in certain circumstances some failures are unavoidable. Here is a list
-common issues we are aware of:</para>
+of the most common issues we are aware of:</para>
 
 <itemizedlist>
 <listitem><para>The <emphasis>math</emphasis> tests sometimes fail when running
@@ -117,20 +117,19 @@ fail due to test timeouts being exceeded.</para></listitem>
 </itemizedlist>
 
 <para>In summary, don't worry too much if you see Glibc test suite failures
-here in this chapter. The Glibc in <xref linkend="chapter-building-system"/> is the one we'll
+here in this chapter. The Glibc in <xref linkend="chapter-building-system"/> is
-ultimately end up using so that is the one we would really like to see pass.
+the one we'll ultimately end up using, so that is the one we would really like
-But please keep in mind, even in <xref linkend="chapter-building-system"/> some failures
+to see pass the tests (but even there some failures could still occur -- the
-could still occur -- the <emphasis>math</emphasis>
+<emphasis>math</emphasis> tests, for example). When experiencing a failure,
-tests for example. When experiencing a failure, make a note of it, then
+make a note of it, then continue by reissuing the <command>make
-continue by reissuing the <command>make check</command>. The test suite
+check</command>. The test suite should pick up where it left off and continue.
-should pick up where it left off and continue on. You can circumvent this
+You can circumvent this stop-start sequence by issuing a <command>make -k
-stop-start sequence by issuing a <command>make -k check</command>. But if
+check</command>. But if you do that, be sure to log the output so that you can
-you do that, be sure to log the output so that you can later peruse the log
+later peruse the log file and examine the total number of failures.</para>
-file and examine the total number of failures.</para>
 
-<para>Though it is a harmless message, the install stage of Glibc will
+<para>Though it is a harmless message, the install stage of Glibc will at the
-complain about the absence of <filename>/tools/etc/ld.so.conf</filename>.
+end complain about the absence of <filename>/tools/etc/ld.so.conf</filename>.
-Fix this annoying little warning with:</para>
+Prevent this confusing little warning with:</para>
 
 <screen><userinput>mkdir /tools/etc
 touch /tools/etc/ld.so.conf</userinput></screen>

chapter05/kernelheaders.xml

@@ -19,8 +19,8 @@ place where <command>gcc</command> can later find them.</para>
 <screen><userinput>make mrproper</userinput></screen>
 
 <para>This ensures that the kernel tree is absolutely clean. The kernel team
-recommends that this command be issued prior to <emphasis>each</emphasis> kernel
+recommends that this command be issued prior to <emphasis>each</emphasis>
-compilation. You shouldn't rely on the source tree being clean after
+kernel compilation. You shouldn't rely on the source tree being clean after
 untarring.</para>
 
 <para>Create the <filename>include/linux/version.h</filename> file:</para>

chapter05/tcl.xml

@@ -20,7 +20,7 @@ test suites for GCC and Binutils. Installing three packages just for testing
 purposes may seem like overkill, but it is very reassuring, if not essential,
 to know that our most important tools are working properly. Even if you are
 not running the test suites here in this chapter as per our recommendation,
-these packages are still required for the test suites in the next
+these packages are still required for running the test suites in the next
 chapter.</para>
 
 <para>Prepare Tcl for compilation:</para>

chapter06/chapter06.xml

@@ -436,13 +436,15 @@ cc dummy.c
 readelf -l a.out | grep ': /lib'</userinput></screen>
 
 <para>If everything is working correctly, there should be no errors, and the
-output of the last command will be:</para>
+output of the last command will be (allowing for platform specific differences
+in dynamic linker name):</para>
 
 <blockquote><screen>[Requesting program interpreter: /lib/ld-linux.so.2]</screen></blockquote>
 
-<para>(Of course allowing for platform specific differences in dynamic linker
+<para>Note especially that <filename class="directory">/lib</filename> is now
-name). Note especially that <filename class="directory">/lib</filename> now
+the prefix of our dynamic linker.</para>
-appears as the prefix of our dynamic linker. If you did not receive the output
+
+<para> If you did not receive the output
 as shown above, or received no output at all, then something is seriously wrong.
 You will need to investigate and retrace your steps to find out where the
 problem is and correct it. There is no point in continuing until this is done.

index.xml

@@ -2,8 +2,8 @@
 <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" 
 			"/usr/share/docbook/docbookx.dtd" [
 
-<!ENTITY version "CVS-2004-02-24">
+<!ENTITY version "CVS-2004-02-25">
-<!ENTITY releasedate "February 24th, 2004">
+<!ENTITY releasedate "February 25th, 2004">
 <!ENTITY milestone "5.2">
 <!ENTITY nbsp " ">