Adding several cross reference tags.

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

24 files changed, 133 insertions, 116 deletions

diff --git a/appendixa/appendixa.xml b/appendixa/appendixa.xml
index 98051a1ef..73ed68d3b 100644
--- a/appendixa/appendixa.xml
+++ b/appendixa/appendixa.xml
@@ -1,4 +1,4 @@
-<appendix id="appendixa">
+<appendix id="appendixa" xreflabel="Appendix A">
 <title>Package descriptions and dependencies</title>
 <?dbhtml filename="appendixa.html" dir="appendixa"?>
 
diff --git a/appendixb/appendixb.xml b/appendixb/appendixb.xml
index f34ebdf6d..83a6da4d0 100644
--- a/appendixb/appendixb.xml
+++ b/appendixb/appendixb.xml
@@ -1,4 +1,4 @@
-<appendix id="appendixb">
+<appendix id="appendixb" xreflabel="Appendix B">
 <title>Index of programs and library files</title>
 <?dbhtml filename="appendixb.html" dir="appendixb"?>
 
diff --git a/chapter01/changelog.xml b/chapter01/changelog.xml
index fda519699..d196542a0 100644
--- a/chapter01/changelog.xml
+++ b/chapter01/changelog.xml
@@ -101,6 +101,9 @@ the <filename>/etc/lfs</filename> filename to
 <filename>/etc/lfs-release</filename> to be more consistent with other
 distributions out there.</para></listitem>
 
+<listitem><para>October 23rd, 2003 [alex]: Changed most of the "Chapter"
+references to proper "xref" cross references .</para></listitem>
+
 <listitem><para>October 22nd, 2003 [gerard] Chapter 2: Added notes how to
 create installation dependency lists.</para></listitem>
 
@@ -416,11 +419,11 @@ used in the gzip installation.  Closes bug 551.</para></listitem>
 patches: Added a note regarding Tushar's patches project, and a link
 to the patches home page.</para></listitem>
 
-<listitem><para>September 3rd, 2003 [matt]: Fixed issue with util-linux not
+<listitem><para>September 3rd, 2003 [matt]: Fixed issue with Util-linux not
 utilizing headers and libraries installed in /stage1.</para></listitem>
 
 <listitem><para>September 3rd, 2003 [matt]: Removed "rm /bin/pwd" instruction
-from chapter06 kernel-headers installation as the link is still required by
+from Chapter 6 kernel-headers installation as the link is still required by
 Glibc's installation.</para></listitem>
 
 <listitem><para>September 2nd, 2003 [alex]: Adjusted all the SBUs from the
diff --git a/chapter01/chapter01.xml b/chapter01/chapter01.xml
index 40e06cedb..17bf587f8 100644
--- a/chapter01/chapter01.xml
+++ b/chapter01/chapter01.xml
@@ -1,4 +1,4 @@
-<chapter id="chapter01">
+<chapter id="chapter01" xreflabel="Chapter 1">
 <title>Introduction</title>
 <?dbhtml filename="chapter01.html" dir="chapter01"?>
 
diff --git a/chapter01/how.xml b/chapter01/how.xml
index 9622937a9..dc6e91fe5 100644
--- a/chapter01/how.xml
+++ b/chapter01/how.xml
@@ -9,60 +9,62 @@ programs like a compiler, linker and shell to build the new system. Normally
 all the required tools are available if you selected <quote>development</quote>
 as one of the options when you installed your distribution.</para>
 
-<para>In Chapter 3 you will first create a new Linux native partition and file
-system, the place where your new LFS system will be compiled and installed. Then
-in Chapter 4 you download all the packages and patches required to build an LFS
-system, and store them on the new file system.</para>
+<para>In <xref linkend="chapter03"/> you will first create a new Linux native
+partition and file system, the place where your new LFS system will be compiled
+and installed. Then in <xref linkend="chapter04"/> you download all the
+packages and patches required to build an LFS system, and store them on the new
+file system.</para>
 
-<para>Chapter 5 will then discuss the installation of a number of packages that
-will form the basic development suite (or toolchain) which is used to build the
-actual system in Chapter 6. Some of these packages are needed to resolve
-circular dependencies. For example, to compile a compiler you need a
-compiler.</para>
+<para><xref linkend="chapter05"/> then discusses the installation of a number
+of packages that will form the basic development suite (or toolchain) which is
+used to build the actual system in <xref linkend="chapter06"/>. Some of these
+packages are needed to resolve circular dependencies -- for example, to compile
+a compiler you need a compiler.</para>
 
-<para>The first thing to be done in Chapter 5 is build a first pass of the 
-toolchain, which is made up of Binutils and GCC. The programs from these 
-packages will be linked statically in order for them to be used independently 
-of the host system. The second thing to do is build Glibc, the C library. Glibc 
-will be compiled by the toolchain programs we just built in the first 
-pass. The third thing to do is build a second pass of the toolchain. This time
-the toolchain will be dynamically linked against the newly built Glibc. The
-remaining Chapter 5 packages are all built using this second pass toolchain and
-dynamically linked against the new host-independent Glibc. When this is done,
-the LFS installation process will no longer depend on the host distribution,
-with the exception of the running kernel.</para>
+<para>The first thing to be done in <xref linkend="chapter05"/> is build a
+first pass of the toolchain, made up of Binutils and GCC. The programs from
+these  packages will be linked statically in order for them to be usable
+independently of the host system. The second thing to do is build Glibc, the
+C library. Glibc will be compiled by the toolchain programs we just built in
+the first pass. The third thing to do is build a second pass of the toolchain.
+This time the toolchain will be dynamically linked against the newly built
+Glibc. The remaining <xref linkend="chapter05"/> packages are all built using
+this second pass toolchain and dynamically linked against the new
+host-independent Glibc. When this is done, the LFS installation process will no
+longer depend on the host distribution, with the exception of the running
+kernel.</para>
 
-<para>You may be asking yourself <quote>that seems like a lot of work, just to
-get away from my host distribution?</quote>. A full technical and in-depth
-explanation is provided at the start of Chapter 5, including some notes on the
-differences between statically and dynamically linked programs.</para>
+<para>You may be thinking that <quote>this seems like a lot of work, just to
+get away from my host distribution</quote>. Well, a full technical explanation
+is provided at the start of <xref linkend="chapter05"/>, including some notes
+on the differences between statically and dynamically linked programs.</para>
 
-<para>In Chapter 6 your real LFS system will be built. The chroot (change root) 
-program is used to enter a virtual environment and start a new shell whose root 
-directory will be set to the LFS partition. This is very similar to rebooting 
-and instructing the kernel to mount the LFS partition as the root partition. 
-The reason that you don't actually reboot, but instead chroot, is that creating 
-a bootable system requires additional work which isn't necessary just yet.
-Another advantage is that chrooting allows you to continue using the host while
-LFS is being built. While waiting for package compilation to complete, you can
-simply switch to a different VC (Virtual Console) or X desktop and continue
-using the computer as you normally would.</para>
+<para>In <xref linkend="chapter06"/> your real LFS system will be built. The
+chroot (change root)  program is used to enter a virtual environment and start
+a new shell whose root directory will be set to the LFS partition. This is very
+similar to rebooting and instructing the kernel to mount the LFS partition as
+the root partition. The reason that you don't actually reboot, but instead
+chroot, is that creating a bootable system requires additional work which isn't
+necessary just yet. But the major advantage is that chrooting allows you to
+continue using the host while LFS is being built. While waiting for package
+compilation to complete, you can simply switch to a different VC (Virtual
+Console) or X desktop and continue using the computer as you normally
+would.</para>
 
-<para>When all the software from Chapter 6 is installed, the temporary tools 
-built in Chapter 5 are removed. In Chapters 7, 8 and 9 the installation will
-then be finalized. The bootscripts are set up in Chapter 7, the kernel and
-bootloader are set up in Chapter 8, and Chapter 9 has some pointers to help
-you after you finish the book.  Then, finally, you're ready to reboot your
-computer into your new LFS system.</para>
+<para>To finish the installation, the bootscripts are set up in
+<xref linkend="chapter07"/>, the kernel and bootloader are set up in
+<xref linkend="chapter08"/>, and <xref linkend="chapter09"/> contains some
+pointers to help you after you finish the book.  Then, finally, you're ready to
+reboot your computer into your new LFS system.</para>
 
 <para>This is the process in a nutshell. Detailed information on the steps you 
 will take are discussed in the chapters and package descriptions as you 
 progress through them. If something isn't completely clear now, don't worry, 
 everything will fall into place soon.</para>
 
-<para>Please read Chapter 2 carefully as it explains a few important things you 
-should be aware of before you begin to work through Chapters 5 and 
-beyond.</para>
+<para>Please read <xref linkend="chapter02"/> carefully as it explains a few
+important things you should be aware of before you begin to work through
+<xref linkend="chapter05"/> and beyond.</para>
 
 </sect1>
 
diff --git a/chapter02/aboutlfs.xml b/chapter02/aboutlfs.xml
index c3c839058..96474e40e 100644
--- a/chapter02/aboutlfs.xml
+++ b/chapter02/aboutlfs.xml
@@ -6,8 +6,8 @@
 variable LFS will be used frequently. $LFS must at all times be replaced with
 the directory where the partition that contains the LFS system is mounted. How
 to create and where to mount the partition will be explained in full detail in
-Chapter 3. For the moment let's assume that the LFS partition is mounted on
-<filename>/mnt/lfs</filename>.</para>
+<xref linkend="chapter03"/>. For the moment let's assume that the LFS partition
+is mounted on <filename>/mnt/lfs</filename>.</para>
 
 <para>When you are told to run a command like
 <userinput>./configure --prefix=$LFS/tools</userinput>, you actually have to
diff --git a/chapter02/chapter02.xml b/chapter02/chapter02.xml
index 435da5e6f..66bfec3f0 100644
--- a/chapter02/chapter02.xml
+++ b/chapter02/chapter02.xml
@@ -1,4 +1,4 @@
-<chapter id="chapter02">
+<chapter id="chapter02" xreflabel="Chapter 2">
 <title>Important information</title>
 <?dbhtml filename="chapter02.html" dir="chapter02"?>
 
diff --git a/chapter03/chapter03.xml b/chapter03/chapter03.xml
index 31a7e074d..4d2ce7dca 100644
--- a/chapter03/chapter03.xml
+++ b/chapter03/chapter03.xml
@@ -1,4 +1,4 @@
-<chapter id="chapter03">
+<chapter id="chapter03" xreflabel="Chapter 3">
 <title>Preparing a new partition</title>
 <?dbhtml filename="chapter03.html" dir="chapter03"?>
 
diff --git a/chapter04/chapter04.xml b/chapter04/chapter04.xml
index 36a04ae34..3944f63dd 100644
--- a/chapter04/chapter04.xml
+++ b/chapter04/chapter04.xml
@@ -1,4 +1,4 @@
-<chapter id="chapter04">
+<chapter id="chapter04" xreflabel="Chapter 4">
 <title>The materials: packages and patches</title>
 <?dbhtml filename="chapter04.html" dir="chapter04"?>
 
diff --git a/chapter05/binutils-pass2-inst.xml b/chapter05/binutils-pass2-inst.xml
index c37070167..55d61844e 100644
--- a/chapter05/binutils-pass2-inst.xml
+++ b/chapter05/binutils-pass2-inst.xml
@@ -30,7 +30,8 @@ variables that override the default optimization flags.</para>
 <screen><userinput>make </userinput></screen>
 
 <note><para>It's worth pointing out that running the Binutils test suite here
-is considered not as important as running it in Chapter 6.</para></note>
+is considered not as important as running it in
+<xref linkend="chapter06"/>.</para></note>
 
 <para>Test the results (there should be no unexpected failures here, expected
 failures are fine):</para>
diff --git a/chapter05/chapter05.xml b/chapter05/chapter05.xml
index fd4d1d65a..44cbf189f 100644
--- a/chapter05/chapter05.xml
+++ b/chapter05/chapter05.xml
@@ -1,4 +1,4 @@
-<chapter id="chapter05">
+<chapter id="chapter05" xreflabel="Chapter 5">
 <title>Constructing a temporary system</title>
 <?dbhtml filename="chapter05.html" dir="chapter05"?>
 
diff --git a/chapter05/gcc-pass2-inst.xml b/chapter05/gcc-pass2-inst.xml
index 08b3b6d33..cd3d4505a 100644
--- a/chapter05/gcc-pass2-inst.xml
+++ b/chapter05/gcc-pass2-inst.xml
@@ -38,11 +38,12 @@ briefly earlier, but a slightly more in-depth explanation of the fixincludes
 process is warranted here.  Under normal circumstances, the GCC fixincludes
 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 Chapter 6,
-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>
+put them in the GCC private include directory.  Then, later on in
+<xref linkend="chapter06"/>, 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 last patch changes GCC's default location of the dynamic linker
 (typically <filename>ld-linux.so.2</filename>). It also removes
@@ -105,7 +106,8 @@ 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>
 
 <note><para>It's worth pointing out that running the GCC test suite here
-is considered not as important as running it in Chapter 6.</para></note>
+is considered not as important as running it in
+<xref linkend="chapter06"/>.</para></note>
 
 <para>Test the results:</para>
 
diff --git a/chapter05/glibc-inst.xml b/chapter05/glibc-inst.xml
index 02da2d905..3e88212f1 100644
--- a/chapter05/glibc-inst.xml
+++ b/chapter05/glibc-inst.xml
@@ -9,8 +9,9 @@ Glibc-linuxthreads in that directory, not in the directory where you usually
 unpack all the sources.</para>
 
 <note><para>We are going to run the test suite for Glibc in this chapter.
-However, it's worth pointing out that running the Glibc test suite here 
-is considered not as important as running it in Chapter 6.</para></note>
+However, it's worth pointing out that running the Glibc test suite here
+is considered not as important as running it in
+<xref linkend="chapter06"/>.</para></note>
 
 <para>This package is known to behave badly when you have changed its
 default optimization flags (including the -march and -mcpu options).
@@ -89,13 +90,13 @@ running the test suite.</para>
 <screen><userinput>make check</userinput></screen>
 
 <para>The Glibc test suite is highly dependent on certain functions of your host
-system, in particular the kernel. Additionally, here in Chapter 5 some tests
+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 Chapter 6. In general, the Glibc test suite is
-always expected to pass. However, as mentioned above, some failures are
-unavoidable in certain circumstances. Here is a list of the most common issues
-we are aware of:</para>
+inside the chroot environment of <xref linkend="chapter06"/>. In general, the
+Glibc test suite is always expected to pass. However, as mentioned above, some
+failures are unavoidable in certain circumstances. Here is a list of the most
+common issues we are aware of:</para>
 
 <itemizedlist>
 <listitem><para>The <emphasis>math</emphasis> tests sometimes fail when running
@@ -118,10 +119,11 @@ the kernel.</para></listitem>
 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 Chapter 5. The Glibc in Chapter 6 is the one we'll ultimately end up using so
-that is the one we would really like to see pass. But please keep in mind, even
-in Chapter 6 some failures could still occur -- the <emphasis>math</emphasis>
+<para>In summary, don't worry too much if you see Glibc test suite failures
+here in this chapter. The Glibc in <xref linkend="chapter06"/> is the one we'll
+ultimately end up using so that is the one we would really like to see pass.
+But please keep in mind, even in <xref linkend="chapter06"/> some failures
+could still occur -- the <emphasis>math</emphasis>
 tests for example. When experiencing a failure, make a note of it, then
 continue by reissuing the <userinput>make check</userinput>. The test suite
 should pick up where it left off and continue on. You can circumvent this
diff --git a/chapter05/tcl-inst.xml b/chapter05/tcl-inst.xml
index 1bd470550..c70070bf5 100644
--- a/chapter05/tcl-inst.xml
+++ b/chapter05/tcl-inst.xml
@@ -18,11 +18,11 @@ to know that our most important tools are working properly.</para>
 <screen><userinput>make</userinput></screen>
 
 <para>This package has a test suite available which can perform a number of
-checks to ensure it built correctly. However, the Tcl test suite here in
-Chapter 5 is known to experience failures under certain host conditions that
-are not fully understood. Therefore, test suite failures here are not
-surprising, but are not considered critical. Should you choose to run the test
-suite, the following command will do so:</para>
+checks to ensure it built correctly. However, the Tcl test suite in this
+chapter is known to experience failures under certain host conditions that are
+not fully understood. Therefore, test suite failures here are not surprising,
+but are not considered critical. Should you choose to run the test suite, the
+following command will do so:</para>
 
 <screen><userinput>TZ=UTC make test</userinput></screen>
 
@@ -33,7 +33,7 @@ suite, the following command will do so:</para>
 Coordinated Universal Time (UTC) also known as Greenwich Mean Time (GMT), but
 only for the duration of the test suite run. This ensures the clock tests are
 exercised correctly. More information on the TZ environment variable is
-available later on in Chapter 7.</para></listitem>
+available later on in <xref linkend="chapter07"/>.</para></listitem>
 </itemizedlist>
 
 <para>Sometimes, package test suites will give false failures.  You can
diff --git a/chapter05/toolchaintechnotes.xml b/chapter05/toolchaintechnotes.xml
index 0b19468db..20f5ddc5c 100644
--- a/chapter05/toolchaintechnotes.xml
+++ b/chapter05/toolchaintechnotes.xml
@@ -7,11 +7,12 @@ details behind the overall build method. It's not essential that you understand
 everything here immediately. Most of it will make sense once you have performed
 an actual build. Feel free to refer back here at any time.</para>
 
-<para>The overall goal of Chapter 5 is to provide a sane, temporary environment
-that we can chroot into, and from which we can produce a clean, trouble-free
-build of the target LFS system in Chapter 6. Along the way, we attempt to
-divorce ourselves from the host system as much as possible, and in so doing
-build a self-contained and self-hosted toolchain. It should be noted that the
+<para>The overall goal of <xref linkend="chapter05"/> is to provide a sane,
+temporary environment that we can chroot into, and from which we can produce a
+clean, trouble-free build of the target LFS system in
+<xref linkend="chapter06"/>. Along the way, we attempt to divorce ourselves
+from the host system as much as possible, and in so doing build a
+self-contained and self-hosted toolchain. It should be noted that the
 build process has been designed in such a way so as to minimize the risks for
 new readers and provide maximum educational value at the same time. In other
 words, more advanced techniques could be used to build the system.</para>
@@ -44,7 +45,8 @@ the <filename>shlib-versions</filename> file in the root of the Glibc source
 tree.</para>
 </important>
 
-<para>Some key technical points of how the Chapter 5 build method works:</para>
+<para>Some key technical points of how the <xref linkend="chapter05"/> build
+method works:</para>
 
 <itemizedlist>
 <listitem><para>Similar in principle to cross compiling whereby tools installed
@@ -128,8 +130,9 @@ hard-wired path to a dynamic linker is embedded into every ELF shared
 executable. You can inspect this by running:
 <userinput>'readelf -l &lt;name of binary&gt; | grep interpreter'</userinput>.
 By amending <userinput>gcc</userinput>'s specs file, we are ensuring that every
-program compiled from here through the end of Chapter 5 will use our new
-dynamic linker in <filename class="directory">/tools/lib</filename>.</para>
+program compiled from here through the end of <xref linkend="chapter05"/> will
+use our new dynamic linker in
+<filename class="directory">/tools/lib</filename>.</para>
 
 <para>The need to use the new dynamic linker is also the reason why we apply the
 Specs patch for the second pass of GCC. Failure to do so will result in the GCC
@@ -141,14 +144,15 @@ would defeat our goal of getting away from the host.</para>
 <emphasis>--with-lib-path</emphasis> configure switch to control
 <userinput>ld</userinput>'s library search path. From this point onwards, the
 core toolchain is self-contained and self-hosted. The remainder of the
-Chapter 5 packages all build against the new Glibc in
+<xref linkend="chapter05"/> packages all build against the new Glibc in
 <filename class="directory">/tools</filename> and all is well.</para>
 
-<para>Upon entering the chroot environment in Chapter 6, the first major package
-we install is Glibc, due to its self-sufficient nature that we mentioned above.
-Once this Glibc is installed into <filename class="directory">/usr</filename>,
-we perform a quick changeover of the toolchain defaults, then proceed for real
-in building the rest of the target Chapter 6 LFS system.</para>
+<para>Upon entering the chroot environment in <xref linkend="chapter06"/>, the
+first major package we install is Glibc, due to its self-sufficient nature that
+we mentioned above. Once this Glibc is installed into
+<filename class="directory">/usr</filename>, we perform a quick changeover of
+the toolchain defaults, then proceed for real in building the rest of the
+target <xref linkend="chapter06"/> LFS system.</para>
 
 <sect2>
 <title>Notes on static linking</title>
@@ -180,14 +184,15 @@ library function gets a bug fixed or is otherwise improved, you only need to
 recompile this one library, instead of having to recompile all the programs that
 make use of the improved function.</para>
 
-<para>Why do we statically link the first two packages in Chapter 5? The reasons
-are threefold: historical, educational and technical. Historical because earlier
-versions of LFS statically linked every program in Chapter 5. Educational
-because knowing the difference is useful. Technical because we gain an element
-of independence from the host in doing so, i.e. those programs can be used
+<para>If dynamic linking has several advantages, why then do we statically link
+the first two packages in this chapter? The reasonsare threefold: historical,
+educational, and technical. Historical, because earlier versions of LFS
+statically linked every program in this chapter. Educational, because knowing
+the difference is useful. Technical, because we gain an element of independence
+from the host in doing so, meaning that those programs can be used
 independently of the host system. However, it's worth noting that an overall
-successful LFS build can still be achieved when the first two packages are built
-dynamically.</para>
+successful LFS build can still be achieved when the first two packages are
+built dynamically.</para>
 
 </sect2>
 
diff --git a/chapter06/aboutdebug.xml b/chapter06/aboutdebug.xml
index e8e179b09..d58737e25 100644
--- a/chapter06/aboutdebug.xml
+++ b/chapter06/aboutdebug.xml
@@ -41,9 +41,9 @@ or ELF binary), run <userinput>strip --strip-debug filename</userinput>.
 Wildcards can be used to treat multiple files (use something like
 <userinput>strip --strip-debug $LFS/tools/bin/*</userinput>).</para>
 
-<para>For your convenience, Chapter 9 includes one simple command to strip
-all debugging symbols from all programs and libraries on your system.
-Additional information on optimization can be found in the hint at
+<para>For your convenience, <xref linkend="chapter09"/> includes one simple
+command to strip all debugging symbols from all programs and libraries on your
+system. Additional information on optimization can be found in the hint at
 <ulink url="&hints-root;optimization.txt"/>.</para>
 
 </sect1>
diff --git a/chapter06/bootscripts-inst.xml b/chapter06/bootscripts-inst.xml
index 8b39d37e7..ef1e60968 100644
--- a/chapter06/bootscripts-inst.xml
+++ b/chapter06/bootscripts-inst.xml
@@ -10,7 +10,8 @@ scripts, to be found at <ulink url="&hints-root;bsd-init.txt"/>. And if you'd
 like something more radical, search the LFS mailing lists for depinit.</para>
 
 <para>If you decide to use BSD style, or some other style scripts, you can
-skip Chapter 7 when you arrive at it and move on to Chapter 8.</para>
+skip the next chapter when you arrive at it and move on to
+<xref linkend="chapter08"/>.</para>
 
 <para>Install the boot scripts:</para>
 
diff --git a/chapter06/chapter06.xml b/chapter06/chapter06.xml
index 6de08e206..9f482c1f7 100644
--- a/chapter06/chapter06.xml
+++ b/chapter06/chapter06.xml
@@ -1,4 +1,4 @@
-<chapter id="chapter06">
+<chapter id="chapter06" xreflabel="Chapter 6">
 <title>Installing basic system software</title>
 <?dbhtml filename="chapter06.html" dir="chapter06"?>
 
diff --git a/chapter06/gcc-2953-inst.xml b/chapter06/gcc-2953-inst.xml
index a45c341fd..782f708bc 100644
--- a/chapter06/gcc-2953-inst.xml
+++ b/chapter06/gcc-2953-inst.xml
@@ -10,7 +10,8 @@ default optimizations, such as CFLAGS and CXXFLAGS, we recommend unsetting
 or modifying them when building GCC.</para>
 
 <para>This is an older release of GCC which we are going to install for the
-purpose of compiling the Linux kernel in Chapter 8. This version is recommended
+purpose of compiling the Linux kernel in <xref linkend="chapter08"/>. This
+version is recommended
 by the kernel developers when you need absolute stability. Later versions of
 GCC have not received as much testing for Linux kernel compilation. Using a
 later version is likely to work, however, we recommend adhering to the kernel
diff --git a/chapter06/procps-inst.xml b/chapter06/procps-inst.xml
index e7a651a9f..000145462 100644
--- a/chapter06/procps-inst.xml
+++ b/chapter06/procps-inst.xml
@@ -3,7 +3,7 @@
 <sect2>
 <title>Installation of Procps</title>
 
-<para>First fix a locale problem that can crash <userinput>w</userinput> under
+<para>First fix a problem that can crash <userinput>w</userinput> under
 certain locale settings:</para>
 
 <screen><userinput>patch -Np1 -i ../&procps-patch;</userinput></screen>
diff --git a/chapter07/chapter07.xml b/chapter07/chapter07.xml
index 03ed18088..c85b1d60c 100644
--- a/chapter07/chapter07.xml
+++ b/chapter07/chapter07.xml
@@ -1,4 +1,4 @@
-<chapter id="chapter07">
+<chapter id="chapter07" xreflabel="Chapter 7">
 <title>Setting up system boot scripts</title>
 <?dbhtml filename="chapter07.html" dir="chapter07"?>
 
diff --git a/chapter07/loadkeys.xml b/chapter07/loadkeys.xml
index 8f8f49e57..7be71947e 100644
--- a/chapter07/loadkeys.xml
+++ b/chapter07/loadkeys.xml
@@ -2,13 +2,13 @@
 <title>Do I need the loadkeys script?</title>
 <?dbhtml filename="loadkeys.html" dir="chapter07"?>
 
-<para>If you decided to compile your keymap file directly into the kernel
-back at the end of Chapter 6, then you strictly speaking don't need to run
-this loadkeys script, since the kernel has already set up the keymap for
-you. You can still run it if you want, it isn't going to hurt you. It could
-even be beneficial to keep it in case you run a lot of different kernels
-and don't remember or want to compile the keymap into every kernel you lay
-your hands on.</para>
+<para>If you decided to compile your keymap file directly into the kernel back
+at the end of <xref linkend="chapter06"/>, then you strictly speaking don't
+need to run this loadkeys script, since the kernel has already set up the
+keymap for you. You can still run it if you want, it isn't going to hurt you.
+It could even be beneficial to keep it in case you run a lot of different
+kernels and don't remember or want to compile the keymap into every kernel you
+lay your hands on.</para>
 
 <para>If you decided you don't need to, or don't want to use the loadkeys
 script, remove the
diff --git a/chapter08/chapter08.xml b/chapter08/chapter08.xml
index 682377c20..258d394f7 100644
--- a/chapter08/chapter08.xml
+++ b/chapter08/chapter08.xml
@@ -1,4 +1,4 @@
-<chapter id="chapter08">
+<chapter id="chapter08" xreflabel="Chapter 8">
 <title>Making the LFS system bootable</title>
 <?dbhtml filename="chapter08.html" dir="chapter08"?>
 
diff --git a/chapter09/chapter09.xml b/chapter09/chapter09.xml
index 48b86a0a4..bb04f7f52 100644
--- a/chapter09/chapter09.xml
+++ b/chapter09/chapter09.xml
@@ -1,4 +1,4 @@
-<chapter id="chapter09">
+<chapter id="chapter09" xreflabel="Chapter 9">
 <title>The End</title>
 <?dbhtml filename="chapter09.html" dir="chapter09"?>