diff options
| -rw-r--r-- | chapter01/changelog.xml | 3 | ||||
| -rw-r--r-- | chapter02/aboutsbus.xml | 6 | ||||
| -rw-r--r-- | chapter02/abouttestsuites.xml | 42 | ||||
| -rw-r--r-- | chapter06/chapter06.xml | 24 | ||||
| -rw-r--r-- | chapter06/gcc.xml | 4 | ||||
| -rw-r--r-- | chapter06/makedev.xml | 8 | ||||
| -rw-r--r-- | chapter06/mountproc.xml | 8 | ||||
| -rw-r--r-- | chapter07/introduction.xml | 8 |
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> |