Adding a few cross references.

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

8 files changed, 53 insertions, 50 deletions

diff --git a/chapter01/changelog.xml b/chapter01/changelog.xml
index 313820acd..9e3412c1e 100644
--- a/chapter01/changelog.xml
+++ b/chapter01/changelog.xml
@@ -55,6 +55,9 @@
 </itemizedlist>
 </listitem>
 
+<listitem><para>January 21st, 2004 [alex]: Chapters 2 and 6 - Making a few
+extra cross references.</para></listitem>
+
 <listitem><para>January 19th, 2004 [greg]: Upgraded to Glibc-2.3.3, Kbd-1.12,
 Perl-5.8.3 and Shadow-4.0.4.1.</para></listitem>
 
diff --git a/chapter02/aboutsbus.xml b/chapter02/aboutsbus.xml
index 2925f8a74..6d0cc1a56 100644
--- a/chapter02/aboutsbus.xml
+++ b/chapter02/aboutsbus.xml
@@ -12,9 +12,9 @@ with the idea of using the <emphasis>Static Binutils Unit</emphasis>
 (abbreviated to <emphasis>SBU</emphasis>).</para>
 
 <para>It works like this: the first package you compile in this book is the
-statically linked Binutils in Chapter 5, and the time it takes to compile this
-package is what we call the "Static Binutils Unit" or "SBU". All other compile
-times will be expressed relative to this time.</para>
+statically linked Binutils in<xref linkend="chapter05"/>, and the time it
+takes to compile this package is what we call the "Static Binutils Unit" or
+"SBU". All other compile times will be expressed relative to this time.</para>
 
 <para>For example, the time it takes to build the static version of GCC is
 &gcc-time-tools-pass1;s. This means that if on your system it took 10 minutes
diff --git a/chapter02/abouttestsuites.xml b/chapter02/abouttestsuites.xml
index 1403629c3..8b4665960 100644
--- a/chapter02/abouttestsuites.xml
+++ b/chapter02/abouttestsuites.xml
@@ -3,9 +3,9 @@
 <?dbhtml filename="abouttestsuites.html" dir="chapter02"?>
 
 <para>Most packages provide a test suite. Running the test suite for a newly
-built package is generally a good idea as it can provide a nice sanity check
-that everything compiled correctly. A test suite that passes its set of
-checks usually proves that the package is functioning mostly as the developer
+built package is generally a good idea, as it can provide a nice sanity check
+that everything compiled correctly. A test suite that passes its set of checks
+usually proves that the package is functioning mostly as the developer
 intended. It does not, however, guarantee that the package is totally bug
 free.</para>
 
@@ -13,29 +13,29 @@ free.</para>
 suites for the core toolchain packages -- GCC, Binutils, and Glibc (the C
 library) -- are of the utmost importance due to their central role in a
 properly functioning system. But be warned, the test suites for GCC and Glibc
-can take a very long period of time to complete, especially on slower
-hardware.</para>
+can take a very long time to complete, especially on slower hardware.</para>
 
 <para>Experience has shown us that there is little to be gained from running
-the test suites in Chapter 5. There can be no escaping the fact that the host
-system always exerts influence on the Chapter 5 tests, often causing weird and
-inexplicable failures. Not only that, the tools built in Chapter 5 are
-temporary and eventually discarded. For the average reader of this book we
-recommend not to run the Chapter 5 test suites. The instructions for running
-the Chapter 5 test suites are still provided for the benefit of testers and
-developers but they are strictly optional for everyone else.</para>
+the test suites in <xref linkend="chapter05"/>. There can be no escaping the
+fact that the host system always exerts influence on the tests in that chapter,
+often causing weird and inexplicable failures. Not only that, the tools built
+in <xref linkend="chapter05"/> are temporary and eventually discarded. For the
+average reader of this book we recommend <emphasis>not</emphasis> to run the
+test suites in <xref linkend="chapter05"/>. The instructions for running those
+test suites are still provided for the benefit of testers and developers, but
+they are strictly optional for everyone else.</para>
 
-<para>As you progress through the book and encounter the build commands to
-run the various test suites, we'll guide you on the relative importance of
-the test suite in question so that you can decide for yourself whether to
-run it or not.</para>
+<para>As you progress through the book and encounter the commands to run the
+various test suites, we'll guide you on the relative importance of the test
+suite in question, so that you can decide for yourself whether to run that one
+or not.</para>
 
 <note><para>A common problem when running the test suites for Binutils and GCC
-is running out of pseudo terminals (PTYs for short). The symptom is an unusually
-high number of failing tests. This can happen for any number of reasons. Most
-likely is that the host system doesn't have the <emphasis>devpts</emphasis> file
-system set up correctly. We'll discuss this in more detail later on in Chapter
-5.</para></note>
+is running out of pseudo terminals (PTYs for short). The symptom is an
+unusually high number of failing tests. This can happen for a number of
+reasons. Most likely is that the host system doesn't have the
+<emphasis>devpts</emphasis> file system set up correctly. We'll discuss this in
+more detail later on in <xref linkend="chapter05"/>.</para></note>
 
 </sect1>
 
diff --git a/chapter06/chapter06.xml b/chapter06/chapter06.xml
index 26e33a9d3..2797dcffc 100644
--- a/chapter06/chapter06.xml
+++ b/chapter06/chapter06.xml
@@ -273,11 +273,11 @@ with a GID of 1, be present. All other group names and GIDs can be chosen
 freely by the user, as well-written packages don't depend on GID numbers but 
 use the group's name.</para>
 
-<para>Lastly, we re-login to the chroot environment.  User name and group name
-resolution will start working immediately after the 
-<filename>/etc/passwd</filename> and <filename>/etc/group</filename> files are 
-created, because we installed a full Glibc in Chapter 5.  This will get rid of 
-the <quote>I have no name!</quote> prompt.</para>
+<para>To get rid of the "I have no name!" prompt, we will start a new shell.
+Since we installed a full Glibc in <xref linkend="chapter05"/>, and have just
+created the <filename>/etc/passwd</filename> and
+<filename>/etc/group</filename> files, user name and group name resolution
+will now work.</para>
 
 <screen><userinput>exec /tools/bin/bash --login +h</userinput></screen>
 
@@ -329,13 +329,13 @@ adjusted linker by running the following from within the
 <screen><userinput>make -C ld INSTALL=/tools/bin/install install</userinput></screen>
 
 <note><para>If you somehow missed the earlier warning to retain the Binutils
-source and build directories from the second pass in Chapter 5 or otherwise
-accidentally deleted them or just don't have access to them, don't worry, all is
-not lost. Just ignore the above command. The result will be that the next
-package, Binutils, will link against the Glibc libraries in
-<filename class="directory">/tools</filename> rather than
-<filename class="directory">/usr</filename>. This is not ideal, however, our
-testing has shown that the resulting Binutils program binaries should be
+source and build directories from the second pass in
+<xref linkend="chapter05"/>, or otherwise accidentally deleted them or just
+don't have access to them, don't worry, all is not lost. Just ignore the above
+command. The result will be that the next package, Binutils, will link against
+the Glibc libraries in <filename class="directory">/tools</filename> rather
+than <filename class="directory">/usr</filename>. This is not ideal, however,
+our testing has shown that the resulting Binutils program binaries should be
 identical.</para></note>
 
 <para>From now on every compiled program will link <emphasis>only</emphasis>
diff --git a/chapter06/gcc.xml b/chapter06/gcc.xml
index db2d3ab1b..9609b8713 100644
--- a/chapter06/gcc.xml
+++ b/chapter06/gcc.xml
@@ -37,7 +37,7 @@ compilers. Instructions for building these can be found at
 <ulink url="&blfs-root;view/stable/general/gcc.html"/>.</para>
 
 <note><para>Be careful <emphasis role="strong">not</emphasis> to apply the GCC
-Specs patch from Chapter 5 here.</para></note>
+Specs patch from <xref linkend="chapter05"/> here.</para></note>
 
 <para>First apply the No-Fixincludes patch that we also used in the previous
 chapter:</para>
@@ -95,7 +95,7 @@ compiler. To satisfy those packages, create a symlink:</para>
 we performed earlier in this chapter. Refer back to
 <xref linkend="ch06-adjustingtoolchain"/> and repeat the check. If the results
 are wrong, then most likely you erroneously applied the GCC Specs patch from
-Chapter 5.</para></note>
+<xref linkend="chapter05"/>.</para></note>
 
 </sect2>
 
diff --git a/chapter06/makedev.xml b/chapter06/makedev.xml
index d48d57cfd..4b273d54e 100644
--- a/chapter06/makedev.xml
+++ b/chapter06/makedev.xml
@@ -48,10 +48,10 @@ Alternatively, you may create devices via the <userinput>mknod</userinput>
 program. Please refer to its man and info pages if you need more
 information.</para>
 
-<para>Additionally, if you were unable to mount the devpts filesystem earlier in
-the "Mounting the proc and devpts file systems" section, now is the time to
-try the alternatives. If your kernel supports the devfs file system, run the
-following command to mount devfs:</para>
+<para>Additionally, if you were unable to mount the devpts filesystem earlier
+in <xref linkend="ch06-proc"/>, now is the time to try the alternatives. If
+your kernel supports the devfs file system, run the following command to mount
+devfs:</para>
 
 <screen><userinput>mount -t devfs devfs /dev</userinput></screen>
 
diff --git a/chapter06/mountproc.xml b/chapter06/mountproc.xml
index c9ce922ea..d9190e8ac 100644
--- a/chapter06/mountproc.xml
+++ b/chapter06/mountproc.xml
@@ -47,11 +47,11 @@ your kernel supports by peeking into its internals with a command such as
 <userinput>cat /proc/filesystems</userinput>. If a file system type named
 <emphasis>devfs</emphasis> is listed there, then we'll be able to work around
 the problem by mounting the host's devfs file system on top of the new
-<filename>/dev</filename> structure which we'll create later on in the
-"Creating devices (Makedev)" section. If devfs was not listed, do not worry
+<filename>/dev</filename> structure which we'll create later on in the section
+on <xref linkend="ch06-MAKEDEV"/>. If devfs was not listed, do not worry
 because there is yet a third way to get PTYs working inside the chroot
-environment. We'll cover this shortly in the aforementioned Makedev
-section.</para>
+environment. We'll cover this shortly in the aforementioned
+<xref linkend="ch06-MAKEDEV"/> section.</para>
 
 <para>Remember, if for any reason you stop working on your LFS, and start again
 later, it's important to check that these filesystems are still mounted inside
diff --git a/chapter07/introduction.xml b/chapter07/introduction.xml
index 5ff7eecea..0e3cdb026 100644
--- a/chapter07/introduction.xml
+++ b/chapter07/introduction.xml
@@ -2,10 +2,10 @@
 <title>Introduction</title>
 <?dbhtml filename="introduction.html" dir="chapter07"?>
 
-<para>This chapter will set up the bootscripts that you installed in chapter
-6. Most of these scripts will work without needing to modify them, but a
-few do require additional configuration files set up as they deal with
-hardware dependent information.</para>
+<para>This chapter will set up the bootscripts you installed in the previous
+chapter. Most of these scripts will work without needing to modify them, but a
+few do require additional configuration files, as they deal with hardware
+dependent information.</para>
 
 </sect1>