r152 - in trunk/BOOK: . chapter01 chapter02 chapter03 prologue

archaic at linuxfromscratch.org archaic at linuxfromscratch.org
Tue Feb 8 14:04:11 PST 2005


Author: archaic
Date: 2005-02-08 15:04:10 -0700 (Tue, 08 Feb 2005)
New Revision: 152

Modified:
   trunk/BOOK/Makefile
   trunk/BOOK/chapter01/administrativa.xml
   trunk/BOOK/chapter02/hostreqs.xml
   trunk/BOOK/chapter02/introduction.xml
   trunk/BOOK/chapter02/ssp.xml
   trunk/BOOK/chapter02/toolchain.xml
   trunk/BOOK/chapter03/introduction.xml
   trunk/BOOK/chapter03/packages.xml
   trunk/BOOK/general.ent
   trunk/BOOK/prologue/bookinfo.xml
   trunk/BOOK/prologue/organization.xml
   trunk/BOOK/prologue/typography.xml
Log:
Miscellaneous fixes. Still getting the framework in order.

Modified: trunk/BOOK/Makefile
===================================================================
--- trunk/BOOK/Makefile	2005-02-08 01:28:53 UTC (rev 151)
+++ trunk/BOOK/Makefile	2005-02-08 22:04:10 UTC (rev 152)
@@ -1,4 +1,4 @@
-BASEDIR=~/public_html/hlfs-book
+BASEDIR=~/hlfs-book
 CHUNK_QUIET=0
 PDF_OUTPUT=HLFS-BOOK.pdf
 NOCHUNKS_OUTPUT=HLFS-BOOK.html

Modified: trunk/BOOK/chapter01/administrativa.xml
===================================================================
--- trunk/BOOK/chapter01/administrativa.xml	2005-02-08 01:28:53 UTC (rev 151)
+++ trunk/BOOK/chapter01/administrativa.xml	2005-02-08 22:04:10 UTC (rev 152)
@@ -41,6 +41,17 @@
 
 </sect2>
 
+<sect2 id="ch-scatter-irc">
+<title>IRC</title>
+
+<para>Several members of the LFS community offer assistance on our community
+Internet Relay Chat (IRC) network. Before using this support, please make sure
+that your question is not already answered in the LFS FAQ or the mailing list
+archives. You can find the IRC network at <uri>irc.linuxfromscratch.org</uri>,
+<uri>irc.linux-phreak.net</uri> or <uri>irc.lfs-matrix.de</uri>. The channel is
+named #HLFS.</para>
+</sect2>
+
 <sect2 id="ch-scatter-mirrors" xreflabel="Chapter 1 - Mirror sites">
 <title>Mirror sites</title>
 

Modified: trunk/BOOK/chapter02/hostreqs.xml
===================================================================
--- trunk/BOOK/chapter02/hostreqs.xml	2005-02-08 01:28:53 UTC (rev 151)
+++ trunk/BOOK/chapter02/hostreqs.xml	2005-02-08 22:04:10 UTC (rev 152)
@@ -7,17 +7,15 @@
 <title>Host System Requirements</title>
 <?dbhtml filename="hostreqs.html"?>
 
-<para>The host must be running at least a 2.6.2 kernel compiled with
-GCC-3.0 or higher. There are two main reasons for this high
-requirement. First, the Native POSIX Threading Library (NPTL)
-test suite will segfault if the host's kernel has not been compiled with
-GCC-3.0 or a later version. Secondly, the 2.6.2 or later version of
-the kernel is required for the use of Udev. Udev creates devices
+<para>The host must be running at least a 2.6.2 kernel compiled with GCC-3.0 or
+higher. There are two main reasons for this high requirement. First, the Native
+POSIX Threading Library (NPTL) test suite will segfault if the host's kernel has
+not been compiled with GCC-3.0 or a later version. Secondly, the 2.6.2 or later
+version of the kernel is required for the use of Udev. Udev creates devices
 dynamically by reading from the <systemitem
-class="filesystem">sysfs</systemitem> file system. However, support
-for this filesystem has only recently been implemented in most of
-the kernel drivers. We must be sure that all critical system devices
-get created properly.</para>
+class="filesystem">sysfs</systemitem> file system. However, support for this
+filesystem has only recently been implemented in most of the kernel drivers. We
+must be sure that all critical system devices get created properly.</para>
 
 <para>In order to determine whether the host kernel meets the
 requirements outlined above, run the following command:</para>
@@ -29,12 +27,11 @@
 <screen><computeroutput>Linux version 2.6.2 (user at host) (gcc version 3.4.0) #1
     Tue Apr 20 21:22:18 GMT 2004</computeroutput></screen>
 
-<para>If the results of the above command state that the host kernel
-was not compiled using a GCC-3.0 (or later) compiler, one will need to
-be compiled.  The host system will then need to be rebooted to use the
-newly compiled kernel. Instructions for compiling the kernel and
-configuring the boot loader (assuming the host uses GRUB) are located
-in <xref linkend="chapter-bootable"/>.</para>
+<para>If the results of the above command state that the host kernel was not
+compiled using a GCC-3.0 (or later) compiler, one will need to be compiled. The
+host system will then need to be rebooted to use the newly compiled kernel.
+Instructions for compiling the kernel and configuring the boot loader (assuming
+the host uses GRUB) are located in <xref linkend="chapter-bootable"/>.</para>
 
 </sect1>
 

Modified: trunk/BOOK/chapter02/introduction.xml
===================================================================
--- trunk/BOOK/chapter02/introduction.xml	2005-02-08 01:28:53 UTC (rev 151)
+++ trunk/BOOK/chapter02/introduction.xml	2005-02-08 22:04:10 UTC (rev 152)
@@ -7,9 +7,9 @@
 <title>Introduction</title>
 <?dbhtml filename="introduction.html"?>
 
-<para>In this chapter, the partition which will host the LFS system is
-prepared. We will create the partition itself, create a file system
-on it, and mount it.</para>
+<para>In this chapter, we will be explaining some of the concepts that make HLFS
+different from LFS. Also, as with LFS, we will provide explanation of the
+process.</para>
 
 </sect1>
 

Modified: trunk/BOOK/chapter02/ssp.xml
===================================================================
--- trunk/BOOK/chapter02/ssp.xml	2005-02-08 01:28:53 UTC (rev 151)
+++ trunk/BOOK/chapter02/ssp.xml	2005-02-08 22:04:10 UTC (rev 152)
@@ -11,16 +11,20 @@
 Hiroaki Etoh for protecting applications from stack smashing attacks. This is
 the single largest class of attacks. There has been some effort to include SSP
 in the mainstream GCC, but this has yet to surface. Many distributions have
-included SSP, some enable it by default while others leave it optional.  This
+included SSP, some enable it by default while others leave it optional. This
 protection uses minimal time and space overhead while protecting all functions.
 Reports of a 1-2% performance loss are typical, which is negligible and can be
 easily overcome by optimizations.</para>
 
-<para>The patch for GCC adds -fstack-protector-all, -fstack-protector, and
--fno-stack-protector* to extensions for C and C++. -Wstack-protector is also
-available to warn when SSP is not used. The patch for Libc adds __guard_setup
-and __stack_smash_handler to libc.so and libc.a. __guard_setup is a function
-used to create a unique and random value for __guard each run time. The Frandom
+<para>The patch for GCC adds <parameter>-fstack-protector-all</parameter>,
+<parameter>-fstack-protector</parameter>, and
+<parameter>-fno-stack-protector</parameter> to extensions for C and C++.
+<parameter>-Wstack-protector</parameter> is also available to warn when SSP is
+not used. The patch for Libc adds <emphasis>__guard_setup</emphasis> and
+<emphasis>__stack_smash_handler</emphasis> to <filename>libc.so</filename> and
+<filename>libc.a</filename>. <emphasis> __guard_setup</emphasis> is a function
+used to create a unique and random value for <emphasis>__guard</emphasis> each
+time it is run. The Frandom
 kernel patch was added to solve an entropy starvation bug caused by SSP needing
 a random seed for every program at run time. Frandom adds the Erandom device
 (economical random) which uses the state of Frandom as a seed. Frandom is seeded

Modified: trunk/BOOK/chapter02/toolchain.xml
===================================================================
--- trunk/BOOK/chapter02/toolchain.xml	2005-02-08 01:28:53 UTC (rev 151)
+++ trunk/BOOK/chapter02/toolchain.xml	2005-02-08 22:04:10 UTC (rev 152)
@@ -7,218 +7,196 @@
 <title>Toolchain Technical Notes</title>
 <?dbhtml filename="toolchaintechnotes.html"?>
 
-<para>This section explains some of the rationale and technical
-details behind the overall build method. It is not essential to
-immediately understand everything in this section. Most of this
-information will be clearer after performing an actual build. This
-section can be referred back to at any time during the process.</para>
+<para>This section explains some of the rationale and technical details behind
+the overall build method. It is not essential to immediately understand
+everything in this section. Most of this information will be clearer after
+performing an actual build. This section can be referred back to at any time
+during the process.</para>
 
-<para>The overall goal of <xref linkend="chapter-temporary-tools"/> is
-to provide a temporary environment that can be chrooted into and from
-which can be produced a clean, trouble-free build of the target LFS
-system in <xref linkend="chapter-building-system"/>. Along the way, we
-separate from the host system as much as possible, and in doing so,
-build a self-contained and self-hosted toolchain. It should be noted
-that the build process has been designed 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>
+<para>The overall goal of <xref linkend="chapter-temporary-tools"/> is to
+provide a temporary environment that can be chrooted into and from which can be
+produced a clean, trouble-free build of the target HLFS system in <xref
+linkend="chapter-building-system"/>. Along the way, we separate from the host
+system as much as possible, and in doing so, build a self-contained and
+self-hosted toolchain. It should be noted that the build process has been
+designed 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>
 
 <important>
-<para>Before continuing, be aware of the name of the working platform,
-often referred to as the target triplet. Many times, the target
-triplet will probably be <emphasis>i686-pc-linux-gnu</emphasis>. A
-simple way to determine the name of the target 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>Before continuing, be aware of the name of the working platform, often
+referred to as the target triplet. Many times, the target triplet will probably
+be <emphasis>i686-pc-linux-gnu</emphasis>. A simple way to determine the name of
+the target 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>Also be aware of the name of the platform's dynamic linker,
-often referred to as the dynamic loader (not to be confused with the
-standard linker <command>ld</command> that is part of Binutils). The
-dynamic linker provided by Glibc finds and loads the shared libraries
-needed by a program, prepares the program to run, and then runs it.
-The name of the dynamic linker will usually be
-<filename class="libraryfile">ld-linux.so.2</filename>. On platforms that are less
-prevalent, the name might be <filename class="libraryfile">ld.so.1</filename>, 
-and newer 64 bit platforms might be named something else entirely. The name of
-the platform's dynamic linker can be determined by looking in the
-<filename class="directory">/lib</filename> directory on the host
-system. A sure-fire way to determine the name is to inspect a random
-binary from the host system by running: <userinput>readelf -l <name
-of binary> | grep interpreter</userinput> and noting the output.
+<para>Also be aware of the name of the platform's dynamic linker, often referred
+to as the dynamic loader (not to be confused with the standard linker
+<command>ld</command> that is part of Binutils). The dynamic linker provided by
+Glibc finds and loads the shared libraries needed by a program, prepares the
+program to run, and then runs it. The name of the dynamic linker will usually be
+<filename class="libraryfile">ld-linux.so.2</filename>. On platforms that are
+less prevalent, the name might be <filename
+class="libraryfile">ld.so.1</filename>, and newer 64 bit platforms might be
+named something else entirely. The name of the platform's dynamic linker can be
+determined by looking in the <filename class="directory">/lib</filename>
+directory on the host system. A sure-fire way to determine the name is to
+inspect a random binary from the host system by running: <userinput>readelf -l
+<name of binary> | grep interpreter</userinput> and noting the output.
 The authoritative reference covering all platforms is in the
-<filename>shlib-versions</filename> file in the root of the Glibc
-source tree.</para>
+<filename>shlib-versions</filename> file in the root of the Glibc source
+tree.</para>
+
 </important>
 
 <beginpage/>
-<para>Some key technical points of how the <xref linkend="chapter-temporary-tools"/> build
-method works:</para>
+<para>Some key technical points of how the <xref
+linkend="chapter-temporary-tools"/> build method works:</para>
 
 <itemizedlist>
-<listitem><para>The process is similar in principle to
-cross-compiling, whereby tools installed in the same prefix work in
-cooperation, and thus utilize a little GNU
-<quote>magic</quote></para></listitem>
+<listitem><para>The process is similar in principle to cross-compiling, whereby
+tools installed in the same prefix work in cooperation, and thus utilize a
+little GNU <quote>magic</quote></para></listitem>
 
-<listitem><para>Careful manipulation of the standard linker's library
-search path ensures programs are linked only against chosen
-libraries</para></listitem>
+<listitem><para>Careful manipulation of the standard linker's library search
+path ensures programs are linked only against chosen libraries</para></listitem>
 
 <listitem><para>Careful manipulation of <command>gcc</command>'s
-<filename>specs</filename> file tell the compiler which target dynamic
-linker will be used</para></listitem>
-</itemizedlist>
+<filename>specs</filename> file tell the compiler which target dynamic linker
+will be used</para></listitem> </itemizedlist>
 
-<para>Binutils is installed first because the
-<command>./configure</command> runs of both GCC and Glibc perform
-various feature tests on the assembler and linker to determine which
-software features to enable or disable. This is more important than
-one might first realize. An incorrectly configured GCC or Glibc can
-result in a subtly broken toolchain, where the impact of such breakage
-might not show up until near the end of the build of an entire
-distribution. A test suite failure will usually alert this error
-before too much additional work is performed.</para>
+<para>Binutils is installed first because the <command>./configure</command>
+runs of both GCC and Glibc perform various feature tests on the assembler and
+linker to determine which software features to enable or disable. This is more
+important than one might first realize. An incorrectly configured GCC or Glibc
+can result in a subtly broken toolchain, where the impact of such breakage might
+not show up until near the end of the build of an entire distribution. A test
+suite failure will usually alert this error before too much additional work is
+performed.</para>
 
-<para>Binutils installs its assembler and linker in two locations,
-<filename class="directory">/tools/bin</filename> and <filename
-class="directory">/tools/$TARGET_TRIPLET/bin</filename>. 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
-<parameter>--verbose</parameter> flag. For example, an <userinput>ld
---verbose | grep SEARCH</userinput> will illustrate the current search
-paths and their order. It shows which files are linked by
-<command>ld</command> by compiling a dummy program and passing the
+<para>Binutils installs its assembler and linker in two locations, <filename
+class="directory">/tools/bin</filename> and <filename
+class="directory">/tools/$TARGET_TRIPLET/bin</filename>. 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 <parameter>--verbose</parameter> flag.
+For example, an <userinput>ld --verbose | grep SEARCH</userinput> will
+illustrate the current search paths and their order. It shows which files are
+linked by <command>ld</command> by compiling a dummy program and passing the
 <parameter>--verbose</parameter> switch to the linker. For example,
-<userinput>gcc dummy.c -Wl,--verbose 2>&1 | grep
-succeeded</userinput> will show all the files successfully opened
-during the linking.</para>
+<userinput>gcc dummy.c -Wl,--verbose 2>&1 | grep succeeded</userinput>
+will show all the files successfully opened during the linking.</para>
 
-<para>The next package installed is GCC. An example of what can be
-seen during its run of <command>./configure</command> is:</para>
+<para>The next package installed is GCC. An example of what can be seen during
+its run of <command>./configure</command> is:</para>
 
 <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>
 
-<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. To find out which standard
-linker <command>gcc</command> will use, run: <userinput>gcc
+<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. To find out which
+standard linker <command>gcc</command> will use, run: <userinput>gcc
 -print-prog-name=ld</userinput>.</para>
 
-<para>Detailed information can be obtained from <command>gcc</command>
-by passing it the <parameter>-v</parameter> command line option while
-compiling a dummy program. For example, <userinput>gcc -v
-dummy.c</userinput> will show detailed information about the
-preprocessor, compilation, and assembly stages, including
-<command>gcc</command>'s included search paths and their order.</para>
+<para>Detailed information can be obtained from <command>gcc</command> by
+passing it the <parameter>-v</parameter> command line option while compiling a
+dummy program. For example, <userinput>gcc -v dummy.c</userinput> will show
+detailed information about the preprocessor, compilation, and assembly stages,
+including <command>gcc</command>'s included search paths and their order.</para>
 
-<para>The next package installed is Glibc. The most important
-considerations for building Glibc are the compiler, binary tools, and
-kernel headers. The compiler is generally not an issue since Glibc
-will always use the <command>gcc</command> found in a 
-<envar>PATH</envar> directory.
-The binary tools and kernel headers can be a bit more complicated.
-Therefore, take no risks and use the available configure switches to
-enforce the correct selections. After the run of
+<para>The next package installed is Glibc. The most important considerations for
+building Glibc are the compiler, binary tools, and kernel headers. The compiler
+is generally not an issue since Glibc will always use the <command>gcc</command>
+found in a <envar>PATH</envar> directory.  The binary tools and kernel headers
+can be a bit more complicated.  Therefore, take no risks and use the available
+configure switches to enforce the correct selections. After the run of
 <command>./configure</command>, check the contents of the
 <filename>config.make</filename> file in the <filename
-class="directory">glibc-build</filename> directory for all important
-details. Note the use of <parameter>CC="gcc -B/tools/bin/"</parameter>
-to control which binary tools are used and the use of the
-<parameter>-nostdinc</parameter> and <parameter>-isystem</parameter>
-flags to control the compiler's include search path. These items
-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>
+class="directory">glibc-build</filename> directory for all important details.
+Note the use of <parameter>CC="gcc -B/tools/bin/"</parameter> to control which
+binary tools are used and the use of the <parameter>-nostdinc</parameter> and
+<parameter>-isystem</parameter> flags to control the compiler's include search
+path. These items 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, make some adjustments to ensure
-that searching and linking take place only within the <filename
+<para>After the Glibc installation, make some adjustments to ensure that
+searching and linking take place only within the <filename
 class="directory">/tools</filename> prefix.  Install an adjusted
-<command>ld</command>, which has a hard-wired search path limited to
-<filename class="directory">/tools/lib</filename>. Then amend
-<command>gcc</command>'s specs file to point to the new dynamic linker
-in <filename class="directory">/tools/lib</filename>. This last step
-is vital to the whole process. As mentioned above, a hard-wired path
-to a dynamic linker is embedded into every Executable and Link Format
-(ELF)-shared executable.  This can be inspected by running:
-<userinput>readelf -l <name of binary> | grep
-interpreter</userinput>. Amending gcc's specs file
-ensures that every program compiled from here through the end of this
-chapter will use the new dynamic linker in <filename
-class="directory">/tools/lib</filename>.</para>
+<command>ld</command>, which has a hard-wired search path limited to <filename
+class="directory">/tools/lib</filename>. Then amend <command>gcc</command>'s
+specs file to point to the new dynamic linker in <filename
+class="directory">/tools/lib</filename>. This last step is vital to the whole
+process. As mentioned above, a hard-wired path to a dynamic linker is embedded
+into every Executable and Link Format (ELF)-shared executable.  This can be
+inspected by running: <userinput>readelf -l <name of binary> | grep
+interpreter</userinput>. Amending gcc's specs file ensures that every program
+compiled from here through the end of this chapter will use the 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
-the Specs patch is applied for the second pass of GCC. Failure to do
-so will result in the GCC programs themselves having the name of the
-dynamic linker from the host system's <filename
-class="directory">/lib</filename> directory embedded into them, which
-would defeat the goal of getting away from the host.</para> 
+<para>The need to use the new dynamic linker is also the reason why the Specs
+patch is applied for the second pass of GCC. Failure to do so will result in the
+GCC programs themselves having the name of the dynamic linker from the host
+system's <filename class="directory">/lib</filename> directory embedded into
+them, which would defeat the goal of getting away from the host.</para> 
 
 <para>During the second pass of Binutils, we are able to utilize the
 <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 <filename
-class="directory">/tools</filename>.</para>
+<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
+<filename class="directory">/tools</filename>.</para>
 
 <para>Upon entering the chroot environment in <xref
-linkend="chapter-building-system"/>, the first major package to be
-installed is Glibc, due to its self-sufficient nature mentioned above.
-Once this Glibc is installed into <filename
-class="directory">/usr</filename>, perform a quick changeover of the
-toolchain defaults, then proceed in building the rest of the target
-LFS system.</para>
+linkend="chapter-building-system"/>, the first major package to be installed is
+Glibc, due to its self-sufficient nature mentioned above. Once this Glibc is
+installed into <filename class="directory">/usr</filename>, perform a quick
+changeover of the toolchain defaults, then proceed in building the rest of the
+target LFS system.</para>
 
 <beginpage/>
 
 <sect2>
 <title>Notes on Static Linking</title>
 
-<para>Besides their specific task, most programs have to perform many
-common and sometimes trivial operations. These include allocating
-memory, searching directories, reading and writing files, string
-handling, pattern matching, arithmetic, and other tasks. Instead of
-obliging each program to reinvent the wheel, the GNU system provides
-all these basic functions in ready-made libraries. The major library
-on any Linux system is Glibc.</para>
+<para>Besides their specific task, most programs have to perform many common and
+sometimes trivial operations. These include allocating memory, searching
+directories, reading and writing files, string handling, pattern matching,
+arithmetic, and other tasks. Instead of obliging each program to reinvent the
+wheel, the GNU system provides all these basic functions in ready-made
+libraries. The major library on any Linux system is Glibc.</para>
 
-<para>There are two primary ways of linking the functions from a
-library to a program that uses them—statically or dynamically. When
-a program is linked statically, the code of the used functions is
-included in the executable, resulting in a rather bulky program. When
-a program is dynamically linked, it includes a reference to the
-dynamic linker, the name of the library, and the name of the function,
-resulting in a much smaller executable. A third option is to use the
-programming interface of the dynamic linker (see the
+<para>There are two primary ways of linking the functions from a library to a
+program that uses them—statically or dynamically. When a program is linked
+statically, the code of the used functions is included in the executable,
+resulting in a rather bulky program. When a program is dynamically linked, it
+includes a reference to the dynamic linker, the name of the library, and the
+name of the function, resulting in a much smaller executable. A third option is
+to use the programming interface of the dynamic linker (see the
 <emphasis>dlopen</emphasis> man page for more information).</para>
 
-<para>Dynamic linking is the default on Linux and has three major
-advantages over static linking. First, only one copy of the executable
-library code is needed on the hard disk, instead of having multiple
-copies of the same code included in several programs, thus saving
-disk space. Second, when several programs use the same library
-function at the same time, only one copy of the function's code is
-required in core, thus saving memory space. Third, when a library
-function gets a bug fixed or is otherwise improved, only the one
-library needs to be recompiled instead of recompiling all programs
-that make use of the improved function.</para>
+<para>Dynamic linking is the default on Linux and has three major advantages
+over static linking. First, only one copy of the executable library code is
+needed on the hard disk, instead of having multiple copies of the same code
+included in several programs, thus saving disk space. Second, when several
+programs use the same library function at the same time, only one copy of the
+function's code is required in core, thus saving memory space. Third, when a
+library function gets a bug fixed or is otherwise improved, only the one library
+needs to be recompiled instead of recompiling all programs that make use of the
+improved function.</para>
 
-<para>If dynamic linking has several advantages, why then do we
-statically link the first two packages in this chapter? The reasons
-are threefold—historical, educational, and technical. The
-historical reason is that earlier versions of LFS statically linked
-every program in this chapter. Educationally, knowing the difference
-between static and dynamic linking is useful. The technical benefit is
-a gained element of independence from the host, meaning that those
-programs can be used independently of the host system. However, it is
-worth noting that an overall successful LFS build can still be
+<para>If dynamic linking has several advantages, why then do we statically link
+the first two packages in this chapter? The reasons are
+threefold—historical, educational, and technical. The historical reason is
+that earlier versions of LFS statically linked every program in this chapter.
+Educationally, knowing the difference between static and dynamic linking is
+useful. The technical benefit is a gained element of independence from the host,
+meaning that those programs can be used independently of the host system.
+However, it is worth noting that an overall successful LFS build can still be
 achieved when the first two packages are built dynamically.</para>
 
 </sect2>

Modified: trunk/BOOK/chapter03/introduction.xml
===================================================================
--- trunk/BOOK/chapter03/introduction.xml	2005-02-08 01:28:53 UTC (rev 151)
+++ trunk/BOOK/chapter03/introduction.xml	2005-02-08 22:04:10 UTC (rev 152)
@@ -16,9 +16,10 @@
 <para>Download locations may not always be accessible. If a download location
 has changed since this book was published, Freshmeat (<ulink
 url="http://www.freshmeat.net"/>) and Google (<ulink
-url="http://www.google.com"/>) provides useful search engines for most packages.
-If this search is unsuccessful, try one of the alternate means of downloading
-discussed at <ulink url="&lfs-root;lfs/packages.html"/>.</para>
+url="http://www.google.com"/>) provide useful search engines for most packages.
+<!--If this search is unsuccessful, try one of the alternate means of downloading
+discussed at <ulink url="&lfs-root;lfs/packages.html"/>.-->
+</para>
 
 </sect1>
 

Modified: trunk/BOOK/chapter03/packages.xml
===================================================================
--- trunk/BOOK/chapter03/packages.xml	2005-02-08 01:28:53 UTC (rev 151)
+++ trunk/BOOK/chapter03/packages.xml	2005-02-08 22:04:10 UTC (rev 152)
@@ -433,7 +433,7 @@
 <varlistentry>
 <term>Util-linux (&util-linux-version;) - ?? KB:</term>
 <listitem>
-<para><ulink url="ftp://ftp.win.tue.nl/pub/home/aeb/linux-local/utils/util-linux/util-linux-2.12q.tar.bz2"/></para>
+<para><ulink url="ftp://ftp.win.tue.nl/pub/home/aeb/linux-local/utils/util-linux/util-linux-2.12q.tar.gz"/></para>
 </listitem>
 </varlistentry>
 

Modified: trunk/BOOK/general.ent
===================================================================
--- trunk/BOOK/general.ent	2005-02-08 01:28:53 UTC (rev 151)
+++ trunk/BOOK/general.ent	2005-02-08 22:04:10 UTC (rev 152)
@@ -46,7 +46,7 @@
 <!ENTITY iproute2-patch-version "2.6.9_ss040831">
 <!ENTITY kbd-version "1.12">
 <!ENTITY less-version "382">
-<!ENTITY lfs-bootscripts-version "3.0-rc1">
+<!ENTITY lfs-bootscripts-version "3.1.0">
 <!ENTITY libol-version "0.3.14">
 <!ENTITY libtool-version "1.5.10">
 <!ENTITY linux-version "2.6.10">
@@ -80,3 +80,4 @@
 <!ENTITY util-linux-version "2.12q">
 <!ENTITY vim-version "6.3">
 <!ENTITY zlib-version "1.2.2">
+

Modified: trunk/BOOK/prologue/bookinfo.xml
===================================================================
--- trunk/BOOK/prologue/bookinfo.xml	2005-02-08 01:28:53 UTC (rev 151)
+++ trunk/BOOK/prologue/bookinfo.xml	2005-02-08 22:04:10 UTC (rev 152)
@@ -28,17 +28,17 @@
 <para>All rights reserved.</para>
 
 <para>Redistribution and use in source and binary forms, with or without
-modification, are permitted provided that the following conditions are
+modification, is permitted provided that the following conditions are
 met:</para>
 
 <itemizedlist>
 
-<listitem><para>Redistributions in any form must retain the above copyright 
-notice, this list of conditions and the following disclaimer.</para></listitem>
+<listitem><para>Redistribution in any form must retain the above copyright 
+notice, this list of conditions, and the following disclaimer:</para></listitem>
 
 <listitem><para>Neither the name of <quote>Linux From Scratch</quote> nor the
 names of its contributors may be used to endorse or promote products derived
-from  this material without specific prior written permission.</para></listitem>
+from this material without specific prior written permission.</para></listitem>
 
 <listitem><para>Any material derived from Linux From Scratch must contain 
 a reference to the <quote>Linux From Scratch</quote> project.</para></listitem>

Modified: trunk/BOOK/prologue/organization.xml
===================================================================
--- trunk/BOOK/prologue/organization.xml	2005-02-08 01:28:53 UTC (rev 151)
+++ trunk/BOOK/prologue/organization.xml	2005-02-08 22:04:10 UTC (rev 152)
@@ -24,7 +24,7 @@
 </sect2>
 
 <sect2>
-<title>Part III - Building the LFS System</title>
+<title>Part III - Building the HLFS System</title>
 
 <para>Part III guides the reader through the building of the HLFS
 system—compiling and installing all the packages one by one, setting up
@@ -34,4 +34,11 @@
 programs, libraries, and important files that have been installed.</para>
 </sect2>
 
+<sect2>
+<title>Part IV - Going Beyond The Basics</title>
+
+<para>Part IV continues beyond the base operating system. Daemons and secure
+clients will be installed and configured as well as other BLFS-type packages
+that require a different configuration than what is in BLFS.</para>
+</sect2>
 </sect1>

Modified: trunk/BOOK/prologue/typography.xml
===================================================================
--- trunk/BOOK/prologue/typography.xml	2005-02-08 01:28:53 UTC (rev 151)
+++ trunk/BOOK/prologue/typography.xml	2005-02-08 22:04:10 UTC (rev 152)
@@ -34,7 +34,7 @@
 book and to external pages such as HOWTOs, download locations and
 websites.</para></blockquote>
 
-<screen><userinput>cat > $LFS/etc/group << "EOF"
+<screen><userinput>cat > $HLFS/etc/group << "EOF"
 root:x:0:
 bin:x:1:
 ......
@@ -42,7 +42,7 @@
 
 <blockquote><para>This type of section is used mainly when creating 
 configuration files. The first command tells the system to create 
-the file <filename>$LFS/etc/group</filename> from whatever is typed on the following lines until 
+the file <filename>$HLFS/etc/group</filename> from whatever is typed on the following lines until 
 the sequence EOF is encountered. Therefore, this whole section is generally 
 typed as seen.</para></blockquote>
 




More information about the hlfs-dev mailing list