cvs commit: LFS/BOOK/stylesheets lfs.css

manuel at linuxfromscratch.org manuel at linuxfromscratch.org
Sun May 30 06:41:04 PDT 2004


manuel      04/05/30 07:41:04

  Modified:    BOOK/chapter05 adjusting.xml binutils-pass1.xml
                        binutils-pass2.xml coreutils.xml dejagnu.xml
                        expect.xml gcc-pass1.xml gcc-pass2.xml gettext.xml
                        glibc.xml grep.xml hostreqs.xml kernel-headers.xml
                        linux-libc-headers.xml ncurses.xml patch.xml
                        perl.xml stripping.xml tcl.xml
                        toolchaintechnotes.xml udev.xml util-linux.xml
               BOOK/stylesheets lfs.css
  Log:
  Tagging corrections in chapters 5.
  
  Revision  Changes    Path
  1.3       +2 -2      LFS/BOOK/chapter05/adjusting.xml
  
  Index: adjusting.xml
  ===================================================================
  RCS file: /home/cvsroot/LFS/BOOK/chapter05/adjusting.xml,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- adjusting.xml	3 May 2004 22:08:10 -0000	1.2
  +++ adjusting.xml	30 May 2004 13:41:03 -0000	1.3
  @@ -20,7 +20,7 @@
   <screen><userinput>make -C ld install</userinput></screen>
   
   <para>From this point onwards everything will link <emphasis>only</emphasis>
  -against the libraries in <filename>/tools/lib</filename>.</para>
  +against the libraries in <filename class="directory">/tools/lib</filename>.</para>
   
   <note><para>If you somehow missed the earlier warning to retain the Binutils
   source and build directories from the first pass or otherwise accidentally
  @@ -77,7 +77,7 @@
   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>
  +<blockquote><screen><computeroutput>[Requesting program interpreter: /tools/lib/ld-linux.so.2]</computeroutput></screen></blockquote>
   
   <para>Note especially that <filename class="directory">/tools/lib</filename>
   appears as the prefix of our dynamic linker.</para>
  
  
  
  1.19      +12 -12    LFS/BOOK/chapter05/binutils-pass1.xml
  
  Index: binutils-pass1.xml
  ===================================================================
  RCS file: /home/cvsroot/LFS/BOOK/chapter05/binutils-pass1.xml,v
  retrieving revision 1.18
  retrieving revision 1.19
  diff -u -r1.18 -r1.19
  --- binutils-pass1.xml	16 May 2004 00:06:08 -0000	1.18
  +++ binutils-pass1.xml	30 May 2004 13:41:03 -0000	1.19
  @@ -32,8 +32,8 @@
   assembler to determine which of their own features to enable.</para>
   
   <para>This package is known to behave badly when you change its default
  -optimization flags (including the <emphasis>-march</emphasis> and
  -<emphasis>-mcpu</emphasis> options). Therefore, if you have defined any
  +optimization flags (including the <parameter>-march</parameter> and
  +<parameter>-mcpu</parameter> options). Therefore, if you have defined any
   environment variables that override default optimizations, such as CFLAGS and
   CXXFLAGS, we recommend un-setting them when building Binutils.</para>
   
  @@ -58,13 +58,13 @@
   
   <variablelist>
   <varlistentry>
  -<term><userinput>--prefix=/tools</userinput></term>
  +<term><parameter>--prefix=/tools</parameter></term>
   <listitem><para>This tells the configure script to prepare to install the Binutils
  -programs in the <filename>/tools</filename> directory.</para></listitem>
  +programs in the <filename class="directory">/tools</filename> directory.</para></listitem>
   </varlistentry>
   
   <varlistentry>
  -<term><userinput>--disable-nls</userinput></term>
  +<term><parameter>--disable-nls</parameter></term>
   <listitem><para>This disables internationalization (a word often shortened to 
   i18n). We don't need this for our static programs and <emphasis>nls</emphasis>
   often causes problems when linking statically.</para></listitem>
  @@ -80,18 +80,18 @@
   
   <variablelist>
   <varlistentry>
  -<term><userinput>configure-host</userinput></term>
  +<term><parameter>configure-host</parameter></term>
   <listitem><para>This forces all the subdirectories to be configured immediately. 
   A statically linked build will fail without it. We therefore use this option to work 
   around the problem.</para></listitem>
   </varlistentry>
   
   <varlistentry>
  -<term><userinput>LDFLAGS="-all-static"</userinput></term>
  +<term><parameter>LDFLAGS="-all-static"</parameter></term>
   <listitem><para>This tells the linker that all the Binutils programs should be 
  -linked statically. However, strictly speaking, <emphasis>"-all-static"</emphasis> 
  +linked statically. However, strictly speaking, <parameter>"-all-static"</parameter>
   is passed to the <command>libtool</command> program, which then passes
  -<emphasis>"-static"</emphasis> to the linker.</para></listitem>
  +<parameter>"-static"</parameter> to the linker.</para></listitem>
   </varlistentry>
   </variablelist>
   
  @@ -114,14 +114,14 @@
   
   <variablelist>
   <varlistentry>
  -<term><userinput>-C ld clean</userinput></term>
  +<term><parameter>-C ld clean</parameter></term>
   <listitem><para>This tells the make program to remove all the compiled files 
   in the <filename class="directory">ld</filename> subdirectory.</para></listitem>
   </varlistentry>
   
   <varlistentry>
  -<term><userinput>-C ld LDFLAGS="-all-static" 
  -LIB_PATH=/tools/lib</userinput></term>
  +<term><parameter>-C ld LDFLAGS="-all-static"
  +LIB_PATH=/tools/lib</parameter></term>
   <listitem><para>This option rebuilds everything in the
   <filename class="directory">ld</filename> subdirectory. Specifying the LIB_PATH
   makefile variable on the command line allows us to override the default value
  
  
  
  1.21      +6 -6      LFS/BOOK/chapter05/binutils-pass2.xml
  
  Index: binutils-pass2.xml
  ===================================================================
  RCS file: /home/cvsroot/LFS/BOOK/chapter05/binutils-pass2.xml,v
  retrieving revision 1.20
  retrieving revision 1.21
  diff -u -r1.20 -r1.21
  --- binutils-pass2.xml	16 May 2004 00:06:08 -0000	1.20
  +++ binutils-pass2.xml	30 May 2004 13:41:03 -0000	1.21
  @@ -38,9 +38,9 @@
   
   <variablelist>
   <varlistentry>
  -<term><userinput>--with-lib-path=/tools/lib</userinput></term>
  +<term><parameter>--with-lib-path=/tools/lib</parameter></term>
   <listitem><para>This tells the configure script to specify the library search path 
  -during the compilation of Binutils, resulting in <emphasis>/tools/lib</emphasis> 
  +during the compilation of Binutils, resulting in <parameter>/tools/lib</parameter>
   to be passed to the linker. This prevents the linker from searching through library 
   directories on the host.</para></listitem>
   </varlistentry>
  @@ -63,9 +63,9 @@
   <para>Except for a few known failures, the binutils tests should all pass. The
   exceptions to this rule are as follows:</para>
   
  -<screen>* 5 FAIL (unexpected failure) for visibility
  +<screen><computeroutput>* 5 FAIL (unexpected failure) for visibility
   * 1 FAIL for selective4
  -* 1 FAIL for selective5</screen>
  +* 1 FAIL for selective5</computeroutput></screen>
   
   <!--
   
  @@ -74,7 +74,7 @@
   was for the GCC package. However, if a failure occurs here, it should be easy
   to spot. The output shown will contain something like:</para>
   
  -<blockquote><screen>make[1]: *** [check-binutils] Error 2</screen></blockquote>
  +<blockquote><screen><computeroutput>make[1]: *** [check-binutils] Error 2</computeroutput></screen></blockquote>
   
   -->
   
  @@ -82,7 +82,7 @@
   
   <screen><userinput>make install</userinput></screen>
   
  -<para>Now prepare the linker for the "Re-adjusting" phase in the next
  +<para>Now prepare the linker for the <quote>Re-adjusting</quote> phase in the next
   chapter:</para>
   
   <screen><userinput>make -C ld clean
  
  
  
  1.22      +5 -5      LFS/BOOK/chapter05/coreutils.xml
  
  Index: coreutils.xml
  ===================================================================
  RCS file: /home/cvsroot/LFS/BOOK/chapter05/coreutils.xml,v
  retrieving revision 1.21
  retrieving revision 1.22
  diff -u -r1.21 -r1.22
  --- coreutils.xml	16 May 2004 00:06:08 -0000	1.21
  +++ coreutils.xml	30 May 2004 13:41:03 -0000	1.22
  @@ -31,17 +31,17 @@
   
   <screen><userinput>DEFAULT_POSIX2_VERSION=199209 ./configure --prefix=/tools</userinput></screen>
   
  -<para>This package has an issue when compiled against versions of glibc
  +<para>This package has an issue when compiled against versions of Glibc
   later than 2.3.2.  Some of the Coreutils utilities (such as
   (<command>head</command>, <command>tail</command> and <command>sort</command>)
   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.  Backwards compatibility is achieved by setting the
  -DEFAULT_POSIX2_VERSION environment variable to "199209" in the above
  -command.  If you don't want coreutils to be backwards compatible
  +DEFAULT_POSIX2_VERSION environment variable to <quote>199209</quote> in the above
  +command.  If you don't want coreutils to be backwards compatible
   with the traditional syntax, then simply omit setting the DEFAULT_POSIX2_VERSION
  -environment variable.  Realise though, that doing so will mean you'll have
  +environment variable.  Realise though, that doing so will mean you'll have
   to deal with the consequences yourself: patch the many packages that still use
   the old syntax.  We therefore recommend using the instructions exactly as given
   above.</para>
  @@ -52,7 +52,7 @@
   
   <para>(If you insist on testing the results, then issue:
   <userinput>make RUN_EXPENSIVE_TESTS=yes check</userinput>. The
  -<emphasis>RUN_EXPENSIVE_TESTS=yes</emphasis> parameter tells the test suite to
  +<parameter>RUN_EXPENSIVE_TESTS=yes</parameter> parameter tells the test suite to
   run several additional tests that are considered relatively expensive on some
   platforms but generally are not a problem on Linux.)</para>
   
  
  
  
  1.15      +1 -1      LFS/BOOK/chapter05/dejagnu.xml
  
  Index: dejagnu.xml
  ===================================================================
  RCS file: /home/cvsroot/LFS/BOOK/chapter05/dejagnu.xml,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -r1.14 -r1.15
  --- dejagnu.xml	24 May 2004 21:37:20 -0000	1.14
  +++ dejagnu.xml	30 May 2004 13:41:03 -0000	1.15
  @@ -53,7 +53,7 @@
   <listitem>
   <indexterm zone="ch-tools-dejagnu runtest"><primary sortas="b-runtest">runtest</primary></indexterm>
   <para>is the wrapper script that finds the proper
  -expect shell and then runs DejaGnu.</para>
  +<command>expect</command> shell and then runs DejaGnu.</para>
   </listitem>
   </varlistentry>
   </variablelist>
  
  
  
  1.19      +3 -3      LFS/BOOK/chapter05/expect.xml
  
  Index: expect.xml
  ===================================================================
  RCS file: /home/cvsroot/LFS/BOOK/chapter05/expect.xml,v
  retrieving revision 1.18
  retrieving revision 1.19
  diff -u -r1.18 -r1.19
  --- expect.xml	24 May 2004 21:37:20 -0000	1.18
  +++ expect.xml	30 May 2004 13:41:03 -0000	1.19
  @@ -42,7 +42,7 @@
   
   <variablelist>
   <varlistentry>
  -<term><userinput>--with-tcl=/tools/lib</userinput></term>
  +<term><parameter>--with-tcl=/tools/lib</parameter></term>
   <listitem><para>This ensures that
   the configure script finds the Tcl installation in our temporary tools location.
   We don't want it to find an existing one that may possibly reside on the host
  @@ -50,7 +50,7 @@
   </varlistentry>
   
   <varlistentry>
  -<term><userinput>--with-x=no</userinput></term>
  +<term><parameter>--with-x=no</parameter></term>
   <listitem><para>This tells the configure
   script not to search for Tk (the Tcl GUI component) or the X Window System
   libraries, both of which may possibly reside on the host system.</para></listitem>
  @@ -75,7 +75,7 @@
   
   <variablelist>
   <varlistentry>
  -<term><userinput>SCRIPTS=""</userinput></term>
  +<term><parameter>SCRIPTS=""</parameter></term>
   <listitem><para>This prevents installation
   of the supplementary expect scripts which are not needed.</para></listitem>
   </varlistentry>
  
  
  
  1.20      +10 -10    LFS/BOOK/chapter05/gcc-pass1.xml
  
  Index: gcc-pass1.xml
  ===================================================================
  RCS file: /home/cvsroot/LFS/BOOK/chapter05/gcc-pass1.xml,v
  retrieving revision 1.19
  retrieving revision 1.20
  diff -u -r1.19 -r1.20
  --- gcc-pass1.xml	16 May 2004 00:06:08 -0000	1.19
  +++ gcc-pass1.xml	30 May 2004 13:41:03 -0000	1.20
  @@ -31,8 +31,8 @@
   nor the test suite here.</para>
   
   <para>This package is known to behave badly when you change its default
  -optimization flags (including the <emphasis>-march</emphasis> and
  -<emphasis>-mcpu</emphasis> options). Therefore, if you have defined any
  +optimization flags (including the <parameter>-march</parameter> and
  +<parameter>-mcpu</parameter> options). Therefore, if you have defined any
   environment variables that override default optimizations, such as CFLAGS and
   CXXFLAGS, we recommend un-setting them when building GCC.</para>
   
  @@ -52,27 +52,27 @@
   
   <variablelist>
   <varlistentry>
  -<term><userinput>--with-local-prefix=/tools</userinput></term>
  -<listitem><para>The purpose of this switch is to remove <filename>/usr/local/include</filename>
  +<term><parameter>--with-local-prefix=/tools</parameter></term>
  +<listitem><para>The purpose of this switch is to remove <filename class="directory">/usr/local/include</filename>
   from <command>gcc</command>'s include search path. This is not absolutely
   essential; however, we want to try to minimize the influence of the host
   system, so this a sensible thing to do.</para></listitem>
   </varlistentry>
   
   <varlistentry>
  -<term><userinput>--enable-shared</userinput></term>
  +<term><parameter>--enable-shared</parameter></term>
   <listitem><para>This switch may
   seem counter-intuitive at first. But using it allows the building of
   <filename>libgcc_s.so.1</filename> and <filename>libgcc_eh.a</filename>, and
   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 <emphasis>-static</emphasis>
  +Note that the GCC binaries will still be linked
  +statically, as this is controlled by the <parameter>-static</parameter>
   value of BOOT_LDFLAGS in the next step.</para></listitem>
   </varlistentry>
   
   <varlistentry>
  -<term><userinput>--enable-languages=c</userinput></term>
  +<term><parameter>--enable-languages=c</parameter></term>
   <listitem><para>This option
   ensures that only the C compiler is built. The option is only needed when you
   have downloaded and unpacked the full GCC tarball.</para></listitem>
  @@ -87,12 +87,12 @@
   
   <variablelist>
   <varlistentry>
  -<term><userinput>BOOT_LDFLAGS="-static"</userinput></term>
  +<term><parameter>BOOT_LDFLAGS="-static"</parameter></term>
   <listitem><para>This tells GCC to link its programs statically.</para></listitem>
   </varlistentry>
   
   <varlistentry>
  -<term><userinput>bootstrap</userinput></term>
  +<term><parameter>bootstrap</parameter></term>
   <listitem><para>This target doesn't just
   compile GCC, but compiles it several times. It uses the programs compiled in
   a first round to compile itself a second time, and then again a third time.
  
  
  
  1.33      +12 -12    LFS/BOOK/chapter05/gcc-pass2.xml
  
  Index: gcc-pass2.xml
  ===================================================================
  RCS file: /home/cvsroot/LFS/BOOK/chapter05/gcc-pass2.xml,v
  retrieving revision 1.32
  retrieving revision 1.33
  diff -u -r1.32 -r1.33
  --- gcc-pass2.xml	20 May 2004 15:59:09 -0000	1.32
  +++ gcc-pass2.xml	30 May 2004 13:41:03 -0000	1.33
  @@ -30,14 +30,14 @@
   in this chapter). One thing to note, however, is that these test suites are
   highly dependent on properly functioning pseudo terminals (PTYs) which are
   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
  +<systemitem class="filesystem">devpts</systemitem> 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>The response might be:</para>
   
  -<blockquote><screen>The system has no more ptys.  Ask your system administrator to create more.</screen></blockquote>
  +<blockquote><screen><computeroutput>The system has no more ptys.  Ask your system administrator to create more.</computeroutput></screen></blockquote>
   
   <para>If you receive the above message, your host doesn't have its PTYs set up
   properly. In this case there is no point in running the test suites for GCC
  @@ -48,17 +48,17 @@
   <para>This time we will build both the C and the C++ compilers, so you'll have
   to unpack both the core and the g++ tarballs (and testsuite too, if you want to
   run the tests). Unpacking them in your working directory, they will all unfold
  -into a single <filename>gcc-&gcc-version;/</filename> subdirectory.</para>
  +into a single <filename class="directory">gcc-&gcc-version;/</filename> subdirectory.</para>
   
   <para>First correct a problem and make an essential adjustment:</para>
   
   <screen><userinput>patch -Np1 -i ../gcc-&gcc-short-version;-no-fixincludes-1.patch
   patch -Np1 -i ../gcc-&gcc-short-version;-specs-1.patch</userinput></screen>
   
  -<para>The first patch disables the GCC <quote>fixincludes</quote> script. We
  +<para>The first patch disables the GCC <command>fixincludes</command> script. We
   mentioned this 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
  +<command>fixincludes</command> 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
   <xref linkend="chapter-building-system"/>, after we've installed the newer
  @@ -98,7 +98,7 @@
   
   <variablelist>
   <varlistentry>
  -<term><userinput>--enable-clocale=gnu</userinput></term>
  +<term><parameter>--enable-clocale=gnu</parameter></term>
   <listitem><para>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>
  @@ -109,13 +109,13 @@
   </varlistentry>
   
   <varlistentry>
  -<term><userinput>--enable-threads=posix</userinput></term>
  +<term><parameter>--enable-threads=posix</parameter></term>
   <listitem><para>This enables
   C++ exception handling for multi-threaded code.</para></listitem>
   </varlistentry>
   
   <varlistentry>
  -<term><userinput>--enable-__cxa_atexit</userinput></term>
  +<term><parameter>--enable-__cxa_atexit</parameter></term>
   <listitem><para>This option
   allows use of __cxa_atexit, rather than atexit, to register C++ destructors for
   local statics and global objects and is essential for fully standards-compliant
  @@ -125,13 +125,13 @@
   </varlistentry>
   
   <varlistentry>
  -<term><userinput>--enable-languages=c,c++</userinput></term>
  +<term><parameter>--enable-languages=c,c++</parameter></term>
   <listitem><para>This option
   ensures that both the C and C++ compilers are built.</para></listitem>
   </varlistentry>
   
   <varlistentry>
  -<term><userinput>--disable-libstdcxx-pch</userinput></term>
  +<term><parameter>--disable-libstdcxx-pch</parameter></term>
   <listitem><para>Don't build the
   PCH (pre-compiled header) for libstdc++. It takes up a ton of space, and we
   have no use for it.</para></listitem>
  @@ -142,7 +142,7 @@
   
   <screen><userinput>make</userinput></screen>
   
  -<para>There is no need to use the <emphasis>bootstrap</emphasis> target now,
  +<para>There is no need to use the <parameter>bootstrap</parameter> target now,
   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>
   
  @@ -153,7 +153,7 @@
   
   <screen><userinput>make -k check</userinput></screen>
   
  -<para>The <emphasis>-k</emphasis> flag is used to make the test suite run
  +<para>The <parameter>-k</parameter> flag is used to make the test suite run
   through to completion and not stop at the first failure. The GCC test suite is
   very comprehensive and is almost guaranteed to generate a few failures. To get
   a summary of the test suite results, run this:</para>
  
  
  
  1.21      +4 -4      LFS/BOOK/chapter05/gettext.xml
  
  Index: gettext.xml
  ===================================================================
  RCS file: /home/cvsroot/LFS/BOOK/chapter05/gettext.xml,v
  retrieving revision 1.20
  retrieving revision 1.21
  diff -u -r1.20 -r1.21
  --- gettext.xml	16 May 2004 00:06:08 -0000	1.20
  +++ gettext.xml	30 May 2004 13:41:03 -0000	1.21
  @@ -36,15 +36,15 @@
   
   <variablelist>
   <varlistentry>
  -<term><userinput>--disable-libasprintf</userinput></term>
  +<term><parameter>--disable-libasprintf</parameter></term>
   <listitem><para>This flag tells
  -Gettext that we don't want its asprintf library.  Nothing in Chapter 5 or 6
  -requires this, and gettext gets rebuilt later, so we exclude it to save
  +Gettext that we don't want its asprintf library.  Nothing in this chapter or the next
  +requires this, and Gettext gets rebuilt later, so we exclude it to save
   time/space.</para></listitem>
   </varlistentry>
   
   <varlistentry>
  -<term><userinput>--disable-csharp</userinput></term>
  +<term><parameter>--disable-csharp</parameter></term>
   <listitem><para>Gettext has a nasty
   habit of searching for a C# compiler on the host, and building bindings for it.
   We've already <quote>locked</quote> ourselves into the temporary tools though,
  
  
  
  1.23      +14 -14    LFS/BOOK/chapter05/glibc.xml
  
  Index: glibc.xml
  ===================================================================
  RCS file: /home/cvsroot/LFS/BOOK/chapter05/glibc.xml,v
  retrieving revision 1.22
  retrieving revision 1.23
  diff -u -r1.22 -r1.23
  --- glibc.xml	16 May 2004 00:06:08 -0000	1.22
  +++ glibc.xml	30 May 2004 13:41:03 -0000	1.23
  @@ -28,8 +28,8 @@
   <title>Installation of Glibc</title>
   
   <para>This package is known to behave badly when you change its default
  -optimization flags (including the <emphasis>-march</emphasis> and
  -<emphasis>-mcpu</emphasis> options). Therefore, if you have defined any
  +optimization flags (including the <parameter>-march</parameter> and
  +<parameter>-mcpu</parameter> options). Therefore, if you have defined any
   environment variables that override default optimizations, such as CFLAGS and
   CXXFLAGS, we recommend un-setting them when building Glibc.</para>
   
  @@ -53,40 +53,40 @@
   
   <variablelist>
   <varlistentry>
  -<term><userinput>--disable-profile</userinput></term>
  +<term><parameter>--disable-profile</parameter></term>
   <listitem><para>This builds the
   libraries without profiling information. Omit this option if you plan to do
   profiling on the temporary tools.</para></listitem>
   </varlistentry>
   
   <varlistentry>
  -<term><userinput>--enable-add-ons=nptl</userinput></term>
  +<term><parameter>--enable-add-ons=nptl</parameter></term>
   <listitem><para>This tells Glibc to use the NPTL add-on as its threading 
   library.</para></listitem>
   </varlistentry>
   
   <varlistentry>
  -<term><userinput>--with-tls</userinput></term>
  +<term><parameter>--with-tls</parameter></term>
   <listitem><para>This tells Glibc to include support for TLS (thread-local storage).
   This is required for NPTL to work. </para></listitem>
   </varlistentry>
   
   <varlistentry>
  -<term><userinput>--with-binutils=/tools/bin</userinput></term>
  +<term><parameter>--with-binutils=/tools/bin</parameter></term>
   <listitem><para>Strictly speaking this switch is not required. But it does ensure 
   nothing can go wrong with regard to what Binutils programs get used during the 
   Glibc build.</para></listitem>
   </varlistentry>
   
   <varlistentry>
  -<term><userinput>--without-gd</userinput></term>
  +<term><parameter>--without-gd</parameter></term>
   <listitem><para>This prevents the build of the <command>memusagestat</command>
   program, which strangely enough insists on linking against the host's libraries 
   (libgd, libpng, libz, and so forth). </para></listitem>
   </varlistentry>
   
   <varlistentry>
  -<term><userinput>--without-cvs</userinput></term>
  +<term><parameter>--without-cvs</parameter></term>
   <listitem><para>This is meant to prevent
   the Makefiles from attempting automatic CVS checkouts when using a CVS
   snapshot. But it's not actually needed these days. We use it because it
  @@ -95,7 +95,7 @@
   </varlistentry>
   
   <varlistentry>
  -<term><userinput>--with-headers=/tools/glibc-kernheaders</userinput></term>
  +<term><parameter>--with-headers=/tools/glibc-kernheaders</parameter></term>
   <listitem><para>This tells Glibc to compile against the <quote>raw</quote> 
   kernel headers, so that it knows exactly what features the kernel has, and can 
   optimize itself accordingly.  Not strictly necessary, but nice to have.</para></listitem>
  @@ -104,10 +104,10 @@
   
   <para>During this stage you might see the following warning:</para>
   
  -<blockquote><screen>configure: WARNING:
  +<blockquote><screen><computeroutput>configure: WARNING:
   *** These auxiliary programs are missing or incompatible versions: msgfmt
   *** some features will be disabled.
  -*** Check the INSTALL file for required versions.</screen></blockquote>
  +*** Check the INSTALL file for required versions.</computeroutput></screen></blockquote>
   
   <para>The missing or incompatible <command>msgfmt</command> program is
   generally harmless, but it's believed it can sometimes cause problems when
  @@ -142,12 +142,12 @@
   host system issues. The exact reasons are not yet clear.</para></listitem>
   
   <listitem><para>The <emphasis>atime</emphasis> test sometimes fails when the
  -LFS partition is mounted with the <emphasis>noatime</emphasis> option, or due
  +LFS partition is mounted with the <parameter>noatime</parameter> option, or due
   to other file system quirks.</para></listitem>
   
   <listitem><para>The <emphasis>shm</emphasis> test might fail when the host
  -system is running the devfs file system but doesn't have the tmpfs file system
  -mounted at <filename>/dev/shm</filename> due to lack of support for tmpfs in
  +system is running the devfs file system but doesn't have the <systemitem class="filesystem">tmpfs</systemitem> file system
  +mounted at <filename class="directory">/dev/shm</filename> due to lack of support for tmpfs in
   the kernel.</para></listitem>
   
   <listitem><para>When running on older and slower hardware, some tests might
  
  
  
  1.27      +2 -2      LFS/BOOK/chapter05/grep.xml
  
  Index: grep.xml
  ===================================================================
  RCS file: /home/cvsroot/LFS/BOOK/chapter05/grep.xml,v
  retrieving revision 1.26
  retrieving revision 1.27
  diff -u -r1.26 -r1.27
  --- grep.xml	16 May 2004 00:06:08 -0000	1.26
  +++ grep.xml	30 May 2004 13:41:03 -0000	1.27
  @@ -36,14 +36,14 @@
   
   <variablelist>
   <varlistentry>
  -<term><userinput>--disable-perl-regexp</userinput></term>
  +<term><parameter>--disable-perl-regexp</parameter></term>
   <listitem><para>This makes sure that <command>grep</command> does not 
   get linked against a PCRE library that may be present on the host and would not be 
   available once we enter the chroot environment.</para></listitem>
   </varlistentry>
   
   <varlistentry>
  -<term><userinput>--with-included-regex</userinput></term>
  +<term><parameter>--with-included-regex</parameter></term>
   <listitem><para>This ensures that
   Grep uses its internal regular expression code. Without this switch, Grep will
   use the code from Glibc, which is known to be slightly buggy.</para></listitem>
  
  
  
  1.4       +1 -1      LFS/BOOK/chapter05/hostreqs.xml
  
  Index: hostreqs.xml
  ===================================================================
  RCS file: /home/cvsroot/LFS/BOOK/chapter05/hostreqs.xml,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- hostreqs.xml	4 May 2004 17:32:06 -0000	1.3
  +++ hostreqs.xml	30 May 2004 13:41:03 -0000	1.4
  @@ -10,7 +10,7 @@
   <para>Due to the experimental nature of the current book, the host must be
   running at <emphasis>least</emphasis> a 2.6.2 kernel. The reasons for this high
   requirement is the use of NPTL, but more importantly the use of udev. Udev
  -creates devices dynamically by reading from the sysfs file system. Only very
  +creates devices dynamically by reading from the <systemitem class="filesystem">sysfs</systemitem> file system. Only very
   recently has support for this file system been implemented in most of the kernel
   drivers, however. We must be sure that all the critical system devices get
   created properly.</para>
  
  
  
  1.4       +1 -1      LFS/BOOK/chapter05/kernel-headers.xml
  
  Index: kernel-headers.xml
  ===================================================================
  RCS file: /home/cvsroot/LFS/BOOK/chapter05/kernel-headers.xml,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- kernel-headers.xml	16 May 2004 00:06:08 -0000	1.3
  +++ kernel-headers.xml	30 May 2004 13:41:03 -0000	1.4
  @@ -41,7 +41,7 @@
   
   <screen><userinput>make include/linux/version.h</userinput></screen>
   
  -<para>Create the platform-specific <filename>include/asm</filename>
  +<para>Create the platform-specific <filename class="symlink">include/asm</filename>
   symlink:</para>
   
   <screen><userinput>make include/asm</userinput></screen>
  
  
  
  1.3       +1 -1      LFS/BOOK/chapter05/linux-libc-headers.xml
  
  Index: linux-libc-headers.xml
  ===================================================================
  RCS file: /home/cvsroot/LFS/BOOK/chapter05/linux-libc-headers.xml,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- linux-libc-headers.xml	16 May 2004 00:06:08 -0000	1.2
  +++ linux-libc-headers.xml	30 May 2004 13:41:03 -0000	1.3
  @@ -25,7 +25,7 @@
   <title>Installation of Linux-Libc-Headers</title>
   
   <para>For years it has been common practice to use so-called <quote>raw</quote>
  -kernel headers (straight from a kernel tarball) in /usr/include, but over the
  +kernel headers (straight from a kernel tarball) in <filename class="directory">/usr/include</filename>, but over the
   last few years, the kernel developers have taken a strong stance that such
   things should not be done.  Thus was born the linux-libc-headers project,
   designed to maintain an API stable version of the Linux headers.</para>
  
  
  
  1.16      +2 -2      LFS/BOOK/chapter05/ncurses.xml
  
  Index: ncurses.xml
  ===================================================================
  RCS file: /home/cvsroot/LFS/BOOK/chapter05/ncurses.xml,v
  retrieving revision 1.15
  retrieving revision 1.16
  diff -u -r1.15 -r1.16
  --- ncurses.xml	16 May 2004 00:06:08 -0000	1.15
  +++ ncurses.xml	30 May 2004 13:41:03 -0000	1.16
  @@ -36,7 +36,7 @@
   
   <variablelist>
   <varlistentry>
  -<term><userinput>--without-ada</userinput></term>
  +<term><parameter>--without-ada</parameter></term>
   <listitem><para>This tells Ncurses not
   to build its Ada bindings, even if an Ada compiler is installed on the host.
   This must be done because once we enter the chroot environment, Ada will no
  @@ -44,7 +44,7 @@
   </varlistentry>
   
   <varlistentry>
  -<term><userinput>--enable-overwrite</userinput></term>
  +<term><parameter>--enable-overwrite</parameter></term>
   <listitem><para>This tells Ncurses to install its header files into 
   <filename class="directory">/tools/include</filename> instead of 
   <filename class="directory">/tools/include/ncurses</filename> to ensure that 
  
  
  
  1.26      +1 -1      LFS/BOOK/chapter05/patch.xml
  
  Index: patch.xml
  ===================================================================
  RCS file: /home/cvsroot/LFS/BOOK/chapter05/patch.xml,v
  retrieving revision 1.25
  retrieving revision 1.26
  diff -u -r1.25 -r1.26
  --- patch.xml	16 May 2004 00:06:08 -0000	1.25
  +++ patch.xml	30 May 2004 13:41:03 -0000	1.26
  @@ -28,7 +28,7 @@
   <title>Installation of Patch</title>
   
   <para>Prepare Patch for compilation (the preprocessor flag
  -<emphasis>-D_GNU_SOURCE</emphasis> is only needed on the PowerPC platform, on
  +<parameter>-D_GNU_SOURCE</parameter> is only needed on the PowerPC platform, on
   other architectures you can leave it out):</para>
   
   <screen><userinput>CPPFLAGS=-D_GNU_SOURCE ./configure --prefix=/tools</userinput></screen>
  
  
  
  1.17      +1 -1      LFS/BOOK/chapter05/perl.xml
  
  Index: perl.xml
  ===================================================================
  RCS file: /home/cvsroot/LFS/BOOK/chapter05/perl.xml,v
  retrieving revision 1.16
  retrieving revision 1.17
  diff -u -r1.16 -r1.17
  --- perl.xml	16 May 2004 00:06:08 -0000	1.16
  +++ perl.xml	30 May 2004 13:41:03 -0000	1.17
  @@ -40,7 +40,7 @@
   
   <variablelist>
   <varlistentry>
  -<term><userinput>-Dstatic_ext='IO Fcntl POSIX'</userinput></term>
  +<term><parameter>-Dstatic_ext='IO Fcntl POSIX'</parameter></term>
   <listitem><para>This tells
   Perl to build the minimum set of static extensions needed for installing and
   testing the Coreutils package in the next chapter.</para></listitem>
  
  
  
  1.2       +1 -1      LFS/BOOK/chapter05/stripping.xml
  
  Index: stripping.xml
  ===================================================================
  RCS file: /home/cvsroot/LFS/BOOK/chapter05/stripping.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- stripping.xml	3 May 2004 10:59:41 -0000	1.1
  +++ stripping.xml	30 May 2004 13:41:03 -0000	1.2
  @@ -20,7 +20,7 @@
   of binaries.</para>
   
   <para>Take care <emphasis>not</emphasis> to use
  -<emphasis>--strip-unneeded</emphasis> on the libraries -- the static ones
  +<parameter>--strip-unneeded</parameter> on the libraries -- the static ones
   would be destroyed and you would have to build the three toolchain packages
   all over again.</para>
   
  
  
  
  1.23      +2 -2      LFS/BOOK/chapter05/tcl.xml
  
  Index: tcl.xml
  ===================================================================
  RCS file: /home/cvsroot/LFS/BOOK/chapter05/tcl.xml,v
  retrieving revision 1.22
  retrieving revision 1.23
  diff -u -r1.22 -r1.23
  --- tcl.xml	24 May 2004 21:37:20 -0000	1.22
  +++ tcl.xml	30 May 2004 13:41:03 -0000	1.23
  @@ -50,7 +50,7 @@
   <userinput>TZ=UTC make test</userinput>. However, the Tcl test suite is known
   to experience failures under certain host conditions that are not fully
   understood. Therefore, test suite failures here are not surprising, and are not
  -considered critical. The <emphasis>TZ=UTC</emphasis> parameter sets the time
  +considered critical. The <parameter>TZ=UTC</parameter> parameter sets the time
   zone to 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
  @@ -61,7 +61,7 @@
   <screen><userinput>make install</userinput></screen>
   
   <warning><para><emphasis>Do not remove</emphasis> the
  -<filename>tcl&tcl-version;</filename> source directory yet, as the next package
  +<filename class="directory">tcl&tcl-version;</filename> source directory yet, as the next package
   will need its internal headers.</para></warning>
   
   <para>Now make a necessary symbolic link:</para>
  
  
  
  1.10      +19 -19    LFS/BOOK/chapter05/toolchaintechnotes.xml
  
  Index: toolchaintechnotes.xml
  ===================================================================
  RCS file: /home/cvsroot/LFS/BOOK/chapter05/toolchaintechnotes.xml,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- toolchaintechnotes.xml	3 May 2004 10:59:41 -0000	1.9
  +++ toolchaintechnotes.xml	30 May 2004 13:41:03 -0000	1.10
  @@ -27,19 +27,19 @@
   platform, often also referred to as the <emphasis>target triplet</emphasis>. For
   many folks the target triplet will probably be
   <emphasis>i686-pc-linux-gnu</emphasis>. A simple way to determine your target
  -triplet is to run the <filename>config.guess</filename> script that comes with
  +triplet is to run the <command>config.guess</command> script that comes with
   the source for many packages. Unpack the Binutils sources and run the script:
   <userinput>./config.guess</userinput> and note the output.</para>
   
   <para>You'll also need to be aware of the name of your platform's
   <emphasis>dynamic linker</emphasis>, often also referred to as the
   <emphasis>dynamic loader</emphasis>, not to be confused with the standard linker
  -<emphasis>ld</emphasis> that is part of Binutils. The dynamic linker is provided
  +<command>ld</command> that is part of Binutils. The dynamic linker is provided
   by Glibc and has the job of finding and loading the shared libraries needed by a
   program, preparing the program to run and then running it. For most folks the
  -name of the dynamic linker will be <emphasis>ld-linux.so.2</emphasis>. On
  +name of the dynamic linker will be <filename>ld-linux.so.2</filename>. On
   platforms that are less prevalent, the name might be
  -<emphasis>ld.so.1</emphasis> and newer 64 bit platforms might even have
  +<filename>ld.so.1</filename> and newer 64 bit platforms might even have
   something completely different. You should be able to determine the name
   of your platform's dynamic linker by looking in the
   <filename class="directory">/lib</filename> directory on your host system. A
  @@ -63,7 +63,7 @@
   choose.</para></listitem>
   
   <listitem><para>Careful manipulation of <command>gcc</command>'s
  -<emphasis>specs</emphasis> file to tell the compiler which target dynamic
  +<filename>specs</filename> file to tell the compiler which target dynamic
   linker will be used.</para></listitem>
   </itemizedlist>
   
  @@ -81,29 +81,29 @@
   <filename class="directory">/tools/$TARGET_TRIPLET/bin</filename>. In reality,
   the tools in one location are hard linked to the other. An important facet of
   the linker is its library search order. Detailed information can be obtained
  -from <command>ld</command> by passing it the <emphasis>--verbose</emphasis>
  +from <command>ld</command> by passing it the <parameter>--verbose</parameter>
   flag. For example: <command>ld --verbose | grep SEARCH</command> will
   show you the current search paths and their order. You can see what files are
   actually linked by <command>ld</command> by compiling a dummy program and
  -passing the <emphasis>--verbose</emphasis> switch to the linker. For example:
  -<command>gcc dummy.c -Wl,--verbose 2>&1 | grep succeeded</command>
  +passing the <parameter>--verbose</parameter> switch to the linker. For example:
  +<userinput>gcc dummy.c -Wl,--verbose 2>&1 | grep succeeded</userinput>
   will show you all the files successfully opened during the linking.</para>
   
   <para>The next package installed is GCC and during its run of
   <command>./configure</command> you'll see, for example:</para>
   
  -<blockquote><screen>checking what assembler to use... /tools/i686-pc-linux-gnu/bin/as
  -checking what linker to use... /tools/i686-pc-linux-gnu/bin/ld</screen></blockquote>
  +<blockquote><screen><computeroutput>checking what assembler to use... /tools/i686-pc-linux-gnu/bin/as
  +checking what linker to use... /tools/i686-pc-linux-gnu/bin/ld</computeroutput></screen></blockquote>
   
   <para>This is important for the reasons mentioned above. It also demonstrates
   that GCC's configure script does not search the PATH directories to find which
   tools to use. However, during the actual operation of <command>gcc</command>
   itself, the same search paths are not necessarily used. You can find out which
   standard linker <command>gcc</command> will use by running:
  -<command>gcc -print-prog-name=ld</command>.
  +<userinput>gcc -print-prog-name=ld</userinput>.
   Detailed information can be obtained from <command>gcc</command> by passing
  -it the <emphasis>-v</emphasis> flag while compiling a dummy program. For
  -example: <command>gcc -v dummy.c</command> will show you detailed
  +it the <parameter>-v</parameter> flag while compiling a dummy program. For
  +example: <userinput>gcc -v dummy.c</userinput> will show you detailed
   information about the preprocessor, compilation and assembly stages, including
   <command>gcc</command>'s include search paths and their order.</para>
    
  @@ -117,15 +117,15 @@
   <filename>config.make</filename> file in the
   <filename class="directory">glibc-build</filename> directory for all the
   important details. You'll note some interesting items like the use of
  -<emphasis>CC="gcc -B/tools/bin/"</emphasis> to control which binary tools are
  -used, and also the use of the <emphasis>-nostdinc</emphasis> and
  -<emphasis>-isystem</emphasis> flags to control the compiler's include search
  +<parameter>CC="gcc -B/tools/bin/"</parameter> to control which binary tools are
  +used, and also the use of the <parameter>-nostdinc</parameter> and
  +<parameter>-isystem</parameter> flags to control the compiler's include search
   path. These items help to highlight an important aspect of the Glibc package:
   it is very self-sufficient in terms of its build machinery and generally does
   not rely on toolchain defaults.</para>
   
   <para>After the Glibc installation, we make some adjustments to ensure that
  -searching and linking take place only within our <filename>/tools</filename>
  +searching and linking take place only within our <filename class="directory">/tools</filename>
   prefix. We install an adjusted <command>ld</command>, which has a hard-wired
   search path limited to <filename class="directory">/tools/lib</filename>. Then
   we amend <command>gcc</command>'s specs file to point to our new dynamic
  @@ -133,7 +133,7 @@
   <emphasis>vital</emphasis> to the whole process. As mentioned above, a
   hard-wired path to a dynamic linker is embedded into every ELF shared
   executable. You can inspect this by running:
  -<command>readelf -l <name of binary> | grep interpreter</command>.
  +<userinput>readelf -l <name of binary> | grep interpreter</userinput>.
   By amending <command>gcc</command>'s specs file, we are ensuring that every
   program compiled from here through the end of this chapter will use our new
   dynamic linker in <filename class="directory">/tools/lib</filename>.</para>
  @@ -145,7 +145,7 @@
   would defeat our goal of getting away from the host.</para>
   
   <para>During the second pass of Binutils, we are able to utilize the
  -<emphasis>--with-lib-path</emphasis> configure switch to control
  +<parameter>--with-lib-path</parameter> configure switch to control
   <command>ld</command>'s library search path. From this point onwards, the
   core toolchain is self-contained and self-hosted. The remainder of the
   <xref linkend="chapter-temporary-tools"/> packages all build against the new Glibc in
  
  
  
  1.5       +1 -2      LFS/BOOK/chapter05/udev.xml
  
  Index: udev.xml
  ===================================================================
  RCS file: /home/cvsroot/LFS/BOOK/chapter05/udev.xml,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- udev.xml	20 May 2004 02:51:48 -0000	1.4
  +++ udev.xml	30 May 2004 13:41:03 -0000	1.5
  @@ -36,8 +36,7 @@
   can easily imagine, this isn't ideal. Give it a much better configuration
   by applying the following patch:</para>
   
  -<screen><userinput>patch -Np1 -i ../udev-&udev-version;-config-2.patch
  -</userinput></screen>
  +<screen><userinput>patch -Np1 -i ../udev-&udev-version;-config-2.patch</userinput></screen>
   
   <para>The udevstart program hardcodes the path to the udev program in itself,
   which is bad since we install udev in a non-standard location. Fix this by
  
  
  
  1.6       +1 -1      LFS/BOOK/chapter05/util-linux.xml
  
  Index: util-linux.xml
  ===================================================================
  RCS file: /home/cvsroot/LFS/BOOK/chapter05/util-linux.xml,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- util-linux.xml	16 May 2004 00:06:08 -0000	1.5
  +++ util-linux.xml	30 May 2004 13:41:03 -0000	1.6
  @@ -33,7 +33,7 @@
   <screen><userinput>patch -Np1 -i ../util-linux-&util-linux-version;-kernel-headers-1.patch</userinput></screen>
   
   <para>Util-linux doesn't use the freshly installed headers and libraries
  -from the /tools directory.  This is fixed by altering the configure
  +from the <filename class="directory">/tools</filename> directory.  This is fixed by altering the configure
   script:</para>
   
   <screen><userinput>sed -i "s@/usr/include@/tools/include at g" configure</userinput></screen>
  
  
  
  1.15      +1 -0      LFS/BOOK/stylesheets/lfs.css
  
  Index: lfs.css
  ===================================================================
  RCS file: /home/cvsroot/LFS/BOOK/stylesheets/lfs.css,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -r1.14 -r1.15
  --- lfs.css	30 May 2004 10:54:18 -0000	1.14
  +++ lfs.css	30 May 2004 13:41:04 -0000	1.15
  @@ -233,6 +233,7 @@
   }
   
   pre.screen {
  +  color: #000;
     background-color: #e9e9e9;
     border: 1px solid #050505;
     padding: .5em 1em;
  
  
  



More information about the lfs-book mailing list