Adding several cross reference tags.

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

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"?>
 

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"?>
 

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

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"?>
 

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
+<para>In <xref linkend="chapter03"/> you will first create a new Linux native
-system, the place where your new LFS system will be compiled and installed. Then
+partition and file system, the place where your new LFS system will be compiled
-in Chapter 4 you download all the packages and patches required to build an LFS
+and installed. Then in <xref linkend="chapter04"/> you download all the
-system, and store them on the new file system.</para>
+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
+<para><xref linkend="chapter05"/> then discusses the installation of a number
-will form the basic development suite (or toolchain) which is used to build the
+of packages that will form the basic development suite (or toolchain) which is
-actual system in Chapter 6. Some of these packages are needed to resolve
+used to build the actual system in <xref linkend="chapter06"/>. Some of these
-circular dependencies. For example, to compile a compiler you need a
+packages are needed to resolve circular dependencies -- for example, to compile
-compiler.</para>
+a compiler you need a compiler.</para>
 
-<para>The first thing to be done in Chapter 5 is build a first pass of the 
+<para>The first thing to be done in <xref linkend="chapter05"/> is build a
-toolchain, which is made up of Binutils and GCC. The programs from these 
+first pass of the toolchain, made up of Binutils and GCC. The programs from
-packages will be linked statically in order for them to be used independently 
+these  packages will be linked statically in order for them to be usable
-of the host system. The second thing to do is build Glibc, the C library. Glibc 
+independently of the host system. The second thing to do is build Glibc, the
-will be compiled by the toolchain programs we just built in the first 
+C library. Glibc will be compiled by the toolchain programs we just built in
-pass. The third thing to do is build a second pass of the toolchain. This time
+the first pass. The third thing to do is build a second pass of the toolchain.
-the toolchain will be dynamically linked against the newly built Glibc. The
+This time the toolchain will be dynamically linked against the newly built
-remaining Chapter 5 packages are all built using this second pass toolchain and
+Glibc. The remaining <xref linkend="chapter05"/> packages are all built using
-dynamically linked against the new host-independent Glibc. When this is done,
+this second pass toolchain and dynamically linked against the new
-the LFS installation process will no longer depend on the host distribution,
+host-independent Glibc. When this is done, the LFS installation process will no
-with the exception of the running kernel.</para>
+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
+<para>You may be thinking that <quote>this seems like a lot of work, just to
-get away from my host distribution?</quote>. A full technical and in-depth
+get away from my host distribution</quote>. Well, a full technical explanation
-explanation is provided at the start of Chapter 5, including some notes on the
+is provided at the start of <xref linkend="chapter05"/>, including some notes
-differences between statically and dynamically linked programs.</para>
+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) 
+<para>In <xref linkend="chapter06"/> your real LFS system will be built. The
-program is used to enter a virtual environment and start a new shell whose root 
+chroot (change root)  program is used to enter a virtual environment and start
-directory will be set to the LFS partition. This is very similar to rebooting 
+a new shell whose root directory will be set to the LFS partition. This is very
-and instructing the kernel to mount the LFS partition as the root partition. 
+similar to rebooting and instructing the kernel to mount the LFS partition as
-The reason that you don't actually reboot, but instead chroot, is that creating 
+the root partition. The reason that you don't actually reboot, but instead
-a bootable system requires additional work which isn't necessary just yet.
+chroot, is that creating a bootable system requires additional work which isn't
-Another advantage is that chrooting allows you to continue using the host while
+necessary just yet. But the major advantage is that chrooting allows you to
-LFS is being built. While waiting for package compilation to complete, you can
+continue using the host while LFS is being built. While waiting for package
-simply switch to a different VC (Virtual Console) or X desktop and continue
+compilation to complete, you can simply switch to a different VC (Virtual
-using the computer as you normally would.</para>
+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 
+<para>To finish the installation, the bootscripts are set up in
-built in Chapter 5 are removed. In Chapters 7, 8 and 9 the installation will
+<xref linkend="chapter07"/>, the kernel and bootloader are set up in
-then be finalized. The bootscripts are set up in Chapter 7, the kernel and
+<xref linkend="chapter08"/>, and <xref linkend="chapter09"/> contains some
-bootloader are set up in Chapter 8, and Chapter 9 has some pointers to help
+pointers to help you after you finish the book.  Then, finally, you're ready to
-you after you finish the book.  Then, finally, you're ready to reboot your
+reboot your computer into your new LFS system.</para>
-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 
+<para>Please read <xref linkend="chapter02"/> carefully as it explains a few
-should be aware of before you begin to work through Chapters 5 and 
+important things you should be aware of before you begin to work through
-beyond.</para>
+<xref linkend="chapter05"/> and beyond.</para>
 
 </sect1>
 

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
+<xref linkend="chapter03"/>. For the moment let's assume that the LFS partition
-<filename>/mnt/lfs</filename>.</para>
+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

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"?>
 

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"?>
 

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"?>
 

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>

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"?>
 

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,
+put them in the GCC private include directory.  Then, later on in
-after we've installed the newer Glibc, this private include directory would be
+<xref linkend="chapter06"/>, after we've installed the newer Glibc, this
-searched before the system include directory, resulting in GCC finding the
+private include directory would be searched before the system include
-fixed headers from the host system, which would most likely not match the Glibc
+directory, resulting in GCC finding the fixed headers from the host system,
-version actually used for the LFS system.</para>
+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>
 

chapter05/glibc-inst.xml

@@ -10,7 +10,8 @@ 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>
+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
+inside the chroot environment of <xref linkend="chapter06"/>. In general, the
-always expected to pass. However, as mentioned above, some failures are
+Glibc test suite is always expected to pass. However, as mentioned above, some
-unavoidable in certain circumstances. Here is a list of the most common issues
+failures are unavoidable in certain circumstances. Here is a list of the most
-we are aware of:</para>
+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
+<para>In summary, don't worry too much if you see Glibc test suite failures
-in Chapter 5. The Glibc in Chapter 6 is the one we'll ultimately end up using so
+here in this chapter. The Glibc in <xref linkend="chapter06"/> is the one we'll
-that is the one we would really like to see pass. But please keep in mind, even
+ultimately end up using so that is the one we would really like to see pass.
-in Chapter 6 some failures could still occur -- the <emphasis>math</emphasis>
+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

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
+checks to ensure it built correctly. However, the Tcl test suite in this
-Chapter 5 is known to experience failures under certain host conditions that
+chapter is known to experience failures under certain host conditions that are
-are not fully understood. Therefore, test suite failures here are not
+not fully understood. Therefore, test suite failures here are not surprising,
-surprising, but are not considered critical. Should you choose to run the test
+but are not considered critical. Should you choose to run the test suite, the
-suite, the following command will do so:</para>
+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

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
+<para>The overall goal of <xref linkend="chapter05"/> is to provide a sane,
-that we can chroot into, and from which we can produce a clean, trouble-free
+temporary environment that we can chroot into, and from which we can produce a
-build of the target LFS system in Chapter 6. Along the way, we attempt to
+clean, trouble-free build of the target LFS system in
-divorce ourselves from the host system as much as possible, and in so doing
+<xref linkend="chapter06"/>. Along the way, we attempt to divorce ourselves
-build a self-contained and self-hosted toolchain. It should be noted that the
+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
+program compiled from here through the end of <xref linkend="chapter05"/> will
-dynamic linker in <filename class="directory">/tools/lib</filename>.</para>
+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
+<para>Upon entering the chroot environment in <xref linkend="chapter06"/>, the
-we install is Glibc, due to its self-sufficient nature that we mentioned above.
+first major package we install is Glibc, due to its self-sufficient nature that
-Once this Glibc is installed into <filename class="directory">/usr</filename>,
+we mentioned above. Once this Glibc is installed into
-we perform a quick changeover of the toolchain defaults, then proceed for real
+<filename class="directory">/usr</filename>, we perform a quick changeover of
-in building the rest of the target Chapter 6 LFS system.</para>
+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
+<para>If dynamic linking has several advantages, why then do we statically link
-are threefold: historical, educational and technical. Historical because earlier
+the first two packages in this chapter? The reasonsare threefold: historical,
-versions of LFS statically linked every program in Chapter 5. Educational
+educational, and technical. Historical, because earlier versions of LFS
-because knowing the difference is useful. Technical because we gain an element
+statically linked every program in this chapter. Educational, because knowing
-of independence from the host in doing so, i.e. those programs can be used
+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
+successful LFS build can still be achieved when the first two packages are
-dynamically.</para>
+built dynamically.</para>
 
 </sect2>
 

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
+<para>For your convenience, <xref linkend="chapter09"/> includes one simple
-all debugging symbols from all programs and libraries on your system.
+command to strip all debugging symbols from all programs and libraries on your
-Additional information on optimization can be found in the hint at
+system. Additional information on optimization can be found in the hint at
 <ulink url="&hints-root;optimization.txt"/>.</para>
 
 </sect1>

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>
 

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"?>
 

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

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>

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"?>
 

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
+<para>If you decided to compile your keymap file directly into the kernel back
-back at the end of Chapter 6, then you strictly speaking don't need to run
+at the end of <xref linkend="chapter06"/>, then you strictly speaking don't
-this loadkeys script, since the kernel has already set up the keymap for
+need to run this loadkeys script, since the kernel has already set up the
-you. You can still run it if you want, it isn't going to hurt you. It could
+keymap for you. You can still run it if you want, it isn't going to hurt you.
-even be beneficial to keep it in case you run a lot of different kernels
+It could even be beneficial to keep it in case you run a lot of different
-and don't remember or want to compile the keymap into every kernel you lay
+kernels and don't remember or want to compile the keymap into every kernel you
-your hands on.</para>
+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

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"?>
 

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"?>