Merge changes developed and tested in the jh branch

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

7 files changed, 199 insertions, 158 deletions

diff --git a/chapter05/binutils-pass1.xml b/chapter05/binutils-pass1.xml
index 610486fa5..b6de18b96 100644
--- a/chapter05/binutils-pass1.xml
+++ b/chapter05/binutils-pass1.xml
@@ -76,15 +76,44 @@ cd ../binutils-build</userinput></screen>
 
     <para>Now prepare Binutils for compilation:</para>
 
-<screen><userinput remap="configure">../binutils-&binutils-version;/configure --target=$LFS_TGT \
-                           --prefix=/tools   \
-                           --disable-nls     \
-                           --disable-werror</userinput></screen>
+<screen><userinput remap="configure">
+../binutils-&binutils-version;/configure     \
+    --prefix=/tools            \
+    --with-sysroot=$LFS        \
+    --with-lib-path=/tools/lib \
+    --target=$LFS_TGT          \
+    --disable-nls              \
+    --disable-werror</userinput></screen>
 
     <variablelist>
       <title>The meaning of the configure options:</title>
 
       <varlistentry>
+        <term><parameter>--prefix=/tools</parameter></term>
+        <listitem>
+          <para>This tells the configure script to prepare to install the
+          Binutils programs in the <filename class="directory">/tools</filename>
+          directory.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><parameter>--with-sysroot=$LFS</parameter></term>
+        <listitem>
+          <para>For cross compilation, this tells the build system to look in
+          $LFS for the target system libraries as needed.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><parameter>--with-lib-path=/tools/lib</parameter></term>
+        <listitem>
+          <para>This specifies which library path the linker should be
+          configured to use.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
         <term><envar>--target=$LFS_TGT</envar></term>
         <listitem>
           <para>Because the machine description in the <envar>LFS_TGT</envar>
@@ -96,22 +125,13 @@ cd ../binutils-build</userinput></screen>
       </varlistentry>
 
       <varlistentry>
-        <term><parameter>--prefix=/tools</parameter></term>
-        <listitem>
-          <para>This tells the configure script to prepare to install the
-          Binutils programs in the <filename class="directory">/tools</filename>
-          directory.</para>
-        </listitem>
-      </varlistentry>
-
-      <varlistentry>
         <term><parameter>--disable-nls</parameter></term>
         <listitem>
           <para>This disables internationalization as i18n is not needed for the
           temporary tools.</para>
         </listitem>
       </varlistentry>
-
+       
       <varlistentry>
         <term><parameter>--disable-werror</parameter></term>
         <listitem>
diff --git a/chapter05/binutils-pass2.xml b/chapter05/binutils-pass2.xml
index 0a3d2df52..cb96b62f0 100644
--- a/chapter05/binutils-pass2.xml
+++ b/chapter05/binutils-pass2.xml
@@ -54,19 +54,20 @@ cd ../binutils-build</userinput></screen>
 
     <para>Prepare Binutils for compilation:</para>
 
-<screen><userinput remap="configure">CC="$LFS_TGT-gcc -B/tools/lib/" \
-AR=$LFS_TGT-ar                  \
-RANLIB=$LFS_TGT-ranlib          \
-../binutils-&binutils-version;/configure      \
-        --prefix=/tools         \
-        --disable-nls           \
-        --with-lib-path=/tools/lib</userinput></screen>
+<screen><userinput remap="configure">
+CC=$LFS_TGT-gcc            \
+AR=$LFS_TGT-ar             \
+RANLIB=$LFS_TGT-ranlib     \
+../binutils-&binutils-version;/configure \
+    --prefix=/tools        \
+    --disable-nls          \
+    --with-lib-path=/tools/lib</userinput></screen>
 
     <variablelist>
       <title>The meaning of the new configure options:</title>
 
       <varlistentry>
-        <term><parameter>CC="$LFS_TGT-gcc -B/tools/lib/" AR=$LFS_TGT-ar RANLIB=$LFS_TGT-ranlib</parameter></term>
+        <term><parameter>CC="$LFS_TGT-gcc" AR=$LFS_TGT-ar RANLIB=$LFS_TGT-ranlib</parameter></term>
         <listitem>
           <para>Because this is really a native build of Binutils, setting these
           variables ensures that the build system uses the cross-compiler and
diff --git a/chapter05/chapter05.xml b/chapter05/chapter05.xml
index 2d957c81b..d6a977d48 100644
--- a/chapter05/chapter05.xml
+++ b/chapter05/chapter05.xml
@@ -18,7 +18,6 @@
   <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="gcc-pass1.xml"/>
   <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="linux-headers.xml"/>
   <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="glibc.xml"/>
-  <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="adjusting.xml"/>
   <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="binutils-pass2.xml"/>
   <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="gcc-pass2.xml"/>
   <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="tcl.xml"/>
diff --git a/chapter05/gcc-pass1.xml b/chapter05/gcc-pass1.xml
index 532bbae36..12d6d48b4 100644
--- a/chapter05/gcc-pass1.xml
+++ b/chapter05/gcc-pass1.xml
@@ -62,6 +62,43 @@ mv -v gmp-&gmp-version; gmp
 tar -zxf ../mpc-&mpc-version;.tar.gz
 mv -v mpc-&mpc-version; mpc</userinput></screen>
 
+    <para>The following command will change the location of GCC's default
+    dynamic linker to use the one installed in <filename
+    class="directory">/tools</filename>. It also removes <filename
+    class="directory">/usr/include</filename> from GCC's include search path.
+    Issue:</para>
+
+<screen><userinput remap="pre">for file in \
+ $(find gcc/config -name linux64.h -o -name linux.h -o -name sysv4.h)
+do
+  cp -uv $file{,.orig}
+  sed -e 's@/lib\(64\)\?\(32\)\?/ld@/tools&amp;@g' \
+      -e 's@/usr@/tools@g' $file.orig &gt; $file
+  echo '
+#undef STANDARD_STARTFILE_PREFIX_1
+#undef STANDARD_STARTFILE_PREFIX_2
+#define STANDARD_STARTFILE_PREFIX_1 "/tools/lib/"
+#define STANDARD_STARTFILE_PREFIX_2 ""' &gt;&gt; $file
+  touch $file.orig
+done</userinput></screen>
+
+    <para>In case the above seems hard to follow, let's break it down a bit.
+    First we find all the files under the <filename
+    class="directory">gcc/config</filename> directory that are named either
+    <filename>linux.h</filename>, <filename>linux64.h</filename> or
+    <filename>sysv4.h</filename>.  For each file found, we copy it to a file of
+    the same name but with an added suffix of <quote>.orig</quote>. Then the
+    first sed expression prepends <quote>/tools</quote> to every instance of
+    <quote>/lib/ld</quote>, <quote>/lib64/ld</quote> or
+    <quote>/lib32/ld</quote>, while the second one replaces hard-coded
+    instances of <quote>/usr</quote>. Next, we add our define statements which
+    alter the default startfile prefix to the end of the file. Note that the
+    trailing <quote>/</quote> in <quote>/tools/lib/</quote> is required.
+    Finally, we use <command>touch</command> to update the timestamp on the
+    copied files.  When used in conjunction with <command>cp -u</command>, this
+    prevents unexpected changes to the original files in case the commands are
+    inadvertently run twice.  </para>
+
     <para>The GCC documentation recommends building GCC outside of the
     source directory in a dedicated build directory:</para>
 
@@ -73,6 +110,11 @@ cd ../gcc-build</userinput></screen>
 <screen><userinput remap="configure">../gcc-&gcc-version;/configure         \
     --target=$LFS_TGT          \
     --prefix=/tools            \
+    --with-sysroot=$LFS        \
+    --with-newlib              \
+    --without-headers          \
+    --with-local-prefix=/tools \
+    --with-native-system-header-dir=/tools/include \
     --disable-nls              \
     --disable-shared           \
     --disable-multilib         \
@@ -83,8 +125,6 @@ cd ../gcc-build</userinput></screen>
     --disable-libgomp          \
     --disable-libquadmath      \
     --enable-languages=c       \
-    --without-ppl              \
-    --without-cloog            \
     --with-mpfr-include=$(pwd)/../gcc-&gcc-version;/mpfr/src \
     --with-mpfr-lib=$(pwd)/mpfr/src/.libs</userinput></screen>
 
@@ -92,6 +132,47 @@ cd ../gcc-build</userinput></screen>
       <title>The meaning of the configure options:</title>
 
       <varlistentry>
+        <term><parameter>--with-newlib</parameter></term>
+        <listitem>
+          <para>Since a working C library is not yet available, this ensures
+          that the inhibit_libc constant is defined when building libgcc. This prevents
+          the compiling of any code that requires libc support.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><parameter>--without-headers</parameter></term>
+        <listitem>
+          <para>When creating a complete cross-compiler, GCC requires
+          standard headers compatible with the target system. For our
+          purposes these headers will not be needed. This switch prevents
+          GCC from looking for them.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><parameter>--with-local-prefix=/tools</parameter></term>
+        <listitem>
+          <para>The local prefix is the location in the system that GCC will search
+          for locally installed include files. The default is <filename>/usr/local</filename>.
+          Setting this to <filename>/tools</filename> helps keep the host location of
+          <filename>/usr/local</filename> out of this GCC's search path.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><parameter>--with-native-system-header-dir=/tools/include</parameter></term>
+        <listitem>
+          <para>By default GCC searches <filename>/usr/include</filename> for system
+          headers. In conjunction with the sysroot switch, this would translate normally
+          to <filename>$LFS/usr/include</filename>. However the headers that will be installed
+          in the next two sections will go to <filename>$LFS/tools/include</filename>. This
+          switch ensures that gcc will find them correctly. In the second pass of GCC, this
+          same switch will ensure that no headers from the host system are found.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
         <term><parameter>--disable-shared</parameter></term>
         <listitem>
           <para>This switch forces GCC to link its internal libraries
@@ -127,15 +208,6 @@ cd ../gcc-build</userinput></screen>
         </listitem>
       </varlistentry>
 
-      <varlistentry>
-        <term><parameter>--without-ppl, --without-cloog</parameter></term>
-        <listitem>
-          <para>These switches prevent GCC from building against the PPL and
-          CLooG libraries which may be present on the host system, but will not
-          be available in the chroot environment.</para>
-        </listitem>
-      </varlistentry>
-
     </variablelist>
 
     <para>Compile GCC by running:</para>
diff --git a/chapter05/gcc-pass2.xml b/chapter05/gcc-pass2.xml
index e2f3cd09c..0ed5c11aa 100644
--- a/chapter05/gcc-pass2.xml
+++ b/chapter05/gcc-pass2.xml
@@ -43,15 +43,20 @@
   <sect2 role="installation">
     <title>Installation of GCC</title>
 
-    <para>Versions of GCC later than 4.3 will treat this build as if
-    it were a relocated compiler and disallow searching for startfiles in
-    the location specified by <parameter>--prefix</parameter>. Since this
-    will not be a relocated compiler, and the startfiles in
-    <filename class="directory">/tools</filename> are crucial to building
-    a working compiler linked to the libs in <filename class="directory">/tools</filename>,
-    apply the following patch which partially reverts GCC to its old behavior:</para>
-
-<screen><userinput remap="pre">patch -Np1 -i ../&gcc-startfiles-patch;</userinput></screen>
+    <para>Our first build of GCC has installed a couple of internal system
+    headers.  Normally one of them, <filename>limits.h</filename> will in turn
+    include the corresponding system <filename>limits.h</filename> header, in
+    this case, <filename>/tools/include/limits.h</filename>. However, at the
+    time of the first build of gcc <filename>/tools/include/limits.h</filename>
+    did not exist, so the internal header that GCC installed is a partial,
+    self-contained file and does not include the extended features of the
+    system header. This was adequate for building the temporary libc, but this
+    build of GCC now requires the full internal header.  Create a full version
+    of the internal header using a command that is identical to what the GCC
+    build system does in normal circumstances:</para>
+
+<screen><userinput remap="pre">cat gcc/limitx.h gcc/glimits.h gcc/limity.h &gt; \
+  `dirname $($LFS_TGT-gcc -print-libgcc-file-name)`/include-fixed/limits.h</userinput></screen>
 
     <para>Under normal circumstances the GCC <command>fixincludes</command> script
     is run in order to fix potentially broken header files. As GCC-&gcc-version;
@@ -76,14 +81,9 @@ sed 's@\./fixinc\.sh@-c true@' gcc/Makefile.in.orig &gt; gcc/Makefile.in</userin
 sed 's/^T_CFLAGS =$/&amp; -fomit-frame-pointer/' gcc/Makefile.in.tmp \
   &gt; gcc/Makefile.in</userinput></screen>
 
-    <para>The following command will change the location of GCC's default
-    dynamic linker to use the one installed in
-    <filename class="directory">/tools</filename>. It also removes <filename
-    class="directory">/usr/include</filename> from GCC's include search path.
-    Doing this now rather than adjusting the specs file after installation
-    ensures that the new dynamic linker is used during the actual build of
-    GCC. That is, all of the binaries created during the build will link
-    against the new Glibc. Issue:</para>
+    <para>Once again, change the location of GCC's default dynamic linker to
+    use the one installed in <filename
+    class="directory">/tools</filename>.</para>
 
 <screen><userinput remap="pre">for file in \
  $(find gcc/config -name linux64.h -o -name linux.h -o -name sysv4.h)
@@ -94,40 +94,11 @@ do
   echo '
 #undef STANDARD_STARTFILE_PREFIX_1
 #undef STANDARD_STARTFILE_PREFIX_2
-#define STANDARD_STARTFILE_PREFIX_1 "/tools/lib"
+#define STANDARD_STARTFILE_PREFIX_1 "/tools/lib/"
 #define STANDARD_STARTFILE_PREFIX_2 ""' &gt;&gt; $file
   touch $file.orig
 done</userinput></screen>
 
-    <para>In case the above seems hard to follow, let's break it down a bit.
-    First we find all the files under the
-    <filename class="directory">gcc/config</filename> directory that are named
-    either <filename>linux.h</filename>, <filename>linux64.h</filename> or
-    <filename>sysv4.h</filename>.
-    For each file found, we copy it to a file of the same name but with an added
-    suffix of <quote>.orig</quote>. Then the first sed expression prepends
-    <quote>/tools</quote> to every instance of <quote>/lib/ld</quote>,
-    <quote>/lib64/ld</quote> or <quote>/lib32/ld</quote>, while the second one
-    replaces hard-coded instances of <quote>/usr</quote>. Then we add our define
-    statements which alter the include search path and the default startfile prefix
-    to the end of the file.
-    Finally, we use <command>touch</command> to update the timestamp on the copied files.
-    When used in conjunction with <command>cp -u</command>, this prevents unexpected
-    changes to the original files in case the commands are inadvertently run twice.
-    </para>
-
-    <para>On x86_64, unsetting the multilib spec for GCC ensures that it
-    won't attempt to link against libraries on the host:</para>
-
-<screen><userinput remap="pre">case $(uname -m) in
-  x86_64)
-    for file in $(find gcc/config -name t-linux64) ; do \
-      cp -v $file{,.orig}
-      sed '/MULTILIB_OSDIRNAMES/d' $file.orig &gt; $file
-    done
-  ;;
-esac</userinput></screen>
-
     <para>As in the first build of GCC it requires the GMP, MPFR and MPC
     packages. Unpack the tarballs and move them into the required directory
     names:</para>
@@ -149,12 +120,13 @@ cd ../gcc-build</userinput></screen>
 
     <para>Now prepare GCC for compilation:</para>
 
-<screen><userinput remap="configure">CC="$LFS_TGT-gcc -B/tools/lib/" \
+<screen><userinput remap="configure">CC="$LFS_TGT-gcc" \
 AR=$LFS_TGT-ar                  \
 RANLIB=$LFS_TGT-ranlib          \
 ../gcc-&gcc-version;/configure          \
     --prefix=/tools             \
     --with-local-prefix=/tools  \
+    --with-native-system-header-dir=/tools/include \
     --enable-clocale=gnu        \
     --enable-shared             \
     --enable-threads=posix      \
@@ -164,8 +136,6 @@ RANLIB=$LFS_TGT-ranlib          \
     --disable-multilib          \
     --disable-bootstrap         \
     --disable-libgomp           \
-    --without-ppl               \
-    --without-cloog             \
     --with-mpfr-include=$(pwd)/../gcc-&gcc-version;/mpfr/src \
     --with-mpfr-lib=$(pwd)/mpfr/src/.libs</userinput></screen>
 
diff --git a/chapter05/glibc.xml b/chapter05/glibc.xml
index 262a85a9f..17caba3d7 100644
--- a/chapter05/glibc.xml
+++ b/chapter05/glibc.xml
@@ -202,6 +202,42 @@ esac</userinput></screen>
 
 <screen><userinput remap="install">make install</userinput></screen>
 
+  <caution>
+    <para>At this point, it is imperative to stop and ensure that the basic
+    functions (compiling and linking) of the new toolchain are working as
+    expected. To perform a sanity check, run the following commands:</para>
+
+<screen><userinput>echo 'main(){}' &gt; dummy.c
+$LFS_TGT-gcc dummy.c
+readelf -l a.out | grep ': /tools'</userinput></screen>
+
+    <para>If everything is working correctly, there should be no errors,
+    and the output of the last command will be of the form:</para>
+
+<screen><computeroutput>[Requesting program interpreter: /tools/lib/ld-linux.so.2]</computeroutput></screen>
+
+    <para>Note that <filename class="directory">/tools/lib</filename>, or
+    <filename class="directory">/tools/lib64</filename> for 64-bit machines
+    appears as the prefix of the dynamic linker.</para>
+
+    <para>If the output is not shown as above or there was no output at all,
+    then something is wrong. Investigate and retrace the steps to find out
+    where the problem is and correct it. This issue must be resolved before
+    continuing on. Something may have gone wrong with the specs file amendment
+    above. In this case, redo the specs file amendment, being careful to
+    copy-and-paste the commands.</para>
+
+    <para>Once all is well, clean up the test files:</para>
+
+<screen><userinput>rm -v dummy.c a.out</userinput></screen>
+
+  </caution>
+
+  <note><para>Building Binutils in the next section will serve as an additional check that
+  the toolchain has been built properly. If Binutils fails to build, it is an
+  indication that something has gone wrong with the previous Binutils, GCC, or Glibc
+  installations.</para></note>
+
   </sect2>
 
   <sect2 role="content">
diff --git a/chapter05/toolchaintechnotes.xml b/chapter05/toolchaintechnotes.xml
index 2932b957f..398f3d104 100644
--- a/chapter05/toolchaintechnotes.xml
+++ b/chapter05/toolchaintechnotes.xml
@@ -71,9 +71,8 @@
       capable hardware.</para>
     </listitem>
     <listitem>
-      <para>Careful manipulation of <command>gcc</command>'s
-      <filename>specs</filename> file tells the compiler which target dynamic
-      linker will be used</para>
+    <para>Careful manipulation of the GCC source tells the compiler which target
+    dynamic linker will be used.</para>
     </listitem>
   </itemizedlist>
 
@@ -118,6 +117,10 @@ checking what linker to use... /tools/i686-lfs-linux-gnu/bin/ld</computeroutput>
   detailed information about the preprocessor, compilation, and assembly stages,
   including <command>gcc</command>'s included search paths and their order.</para>
 
+  <para>Next installed are sanitized Linux API headers. These allow the standard
+  C library (Glibc) to interface with features that the Linux kernel will
+  provide.</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 compiler
@@ -136,31 +139,19 @@ checking what linker to use... /tools/i686-lfs-linux-gnu/bin/ld</computeroutput>
   package&mdash;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, change <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 in ensuring
-  that searching and linking take place only within the <filename
-  class="directory">/tools</filename> prefix. 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 &lt;name of binary&gt; | grep interpreter</userinput>.
-  Amending <command>gcc</command>'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>For the second pass of GCC, its sources also need to be modified
-  to tell GCC to use the new dynamic linker. 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.</para>
+
+  <para>For the second pass of GCC, its sources also need to be modified to
+  tell GCC to use the new dynamic linker. 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. 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
@@ -170,52 +161,4 @@ checking what linker to use... /tools/i686-lfs-linux-gnu/bin/ld</computeroutput>
   toolchain defaults, and then proceed in building the rest of the target
   LFS system.</para>
 
-  <!-- FIXME: Removed as part of the fix for bug 1061 - we no longer build pass1
-      packages statically, therefore this explanation isn't required
-
-  <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>There are two primary ways of linking the functions from a
-  library to a program that uses them&mdash;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 <filename>dlopen(3)</filename>
-  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>If dynamic linking has several advantages, why then do we
-  statically link the first two packages in this chapter? The reasons
-  are threefold&mdash;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>-->
-
 </sect1>