Bring in DIY's next generation build method. Move GRUB to chapter 8.

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

1 files changed, 19 insertions, 58 deletions

diff --git a/chapter05/adjusting.xml b/chapter05/adjusting.xml
index a916e3621..dc02f05e5 100644
--- a/chapter05/adjusting.xml
+++ b/chapter05/adjusting.xml
@@ -12,26 +12,13 @@
 
   <para>Now that the temporary C libraries have been installed, all
   tools compiled in the rest of this chapter should be linked against
-  these libraries. In order to accomplish this, the linker and the
-  compiler's specs file need to be adjusted.</para>
-
-  <para>The linker, adjusted at the end of the first pass of Binutils, needs
-  to be renamed so that it can be properly found and used. First, backup the
-  original linker, then replace it with the adjusted linker. We'll also
-  create a link to its counterpart in <filename class="directory">
-  /tools/$(gcc -dumpmachine)/bin</filename>:</para>
-
-<screen><userinput>mv -v /tools/bin/{ld,ld-old}
-mv -v /tools/$(gcc -dumpmachine)/bin/{ld,ld-old}
-mv -v /tools/bin/{ld-new,ld}
-ln -sv /tools/bin/ld /tools/$(gcc -dumpmachine)/bin/ld</userinput></screen>
-
-  <para>From this point onwards, everything will link only against the
-  libraries in <filename class="directory">/tools/lib</filename>.</para>
-
-  <para>The next task is to point GCC to the new dynamic linker. This is done by
-  dumping GCC's <quote>specs</quote> file to a location where GCC will look for it
-  by default. A simple <command>sed</command> substitution then alters the
+  these libraries. In order to accomplish this, the cross-compiler's
+  specs file needs to be adjusted to point to the new dynamic linker
+  in <filename class="directory">/tools</filename>.</para>
+
+  <para>This is done by dumping the compiler's <quote>specs</quote> file to a
+  location where it will look for it by default.
+  A simple <command>sed</command> substitution then alters the
   dynamic linker that GCC will use. The principle here is to find all references
   to the dynamic linker file in <filename class="directory">/lib</filename>
   or possibly <filename class="directory">/lib64</filename> if the host system
@@ -46,28 +33,12 @@ ln -sv /tools/bin/ld /tools/$(gcc -dumpmachine)/bin/ld</userinput></screen>
   of the dynamic linker, if necessary.</para>
 
 <!-- Ampersands are needed to allow copy and paste -->
-<screen><userinput>gcc -dumpspecs | sed 's@/lib\(64\)\?/ld@/tools&amp;@g' &gt; \
-  `dirname $(gcc -print-libgcc-file-name)`/specs</userinput></screen>
-
-  <para>During the build process, GCC runs a script
-  (<command>fixincludes</command>) that scans the system for header files
-  that may need to be fixed (they might contain syntax errors, for example),
-  and installs the fixed versions in a private include directory. There is a
-  possibility that, as a result of this process, some header files from the
-  host system have found their way into GCC's private include directory. As
-  the rest of this chapter only requires the headers from GCC and Glibc,
-  which have both been installed at this point, any <quote>fixed</quote>
-  headers can safely be removed. This helps to avoid any host headers
-  polluting the build environment. Run the following commands to remove the
-  header files in GCC's private include directory (you may find it easier to
-  copy and paste these commands, rather than typing them by hand, due to
-  their length):</para>
-
-<!-- && used to ease copy and pasting -->
-<screen><userinput>GCC_FIXED=`dirname $(gcc -print-libgcc-file-name)`/include-fixed &amp;&amp;
-find ${GCC_FIXED}/* -maxdepth 0 -xtype d -exec rm -rvf '{}' \; &amp;&amp;
-rm -vf `grep -l "DO NOT EDIT THIS FILE" ${GCC_FIXED}/*` &amp;&amp;
-unset GCC_FIXED</userinput></screen>
+<screen><userinput>SPECS=`dirname $($LFS_TGT-gcc -print-libgcc-file-name)`/specs
+$LFS_TGT-gcc -dumpspecs | sed \
+  -e 's@/lib\(64\)\?/ld@/tools&amp;@g' \
+  -e "/^\*cpp:$/{n;s,$, -isystem /tools/include,}" &gt; $SPECS 
+echo "New specs file is: $SPECS"
+unset SPECS</userinput></screen>
 
   <caution>
     <para>At this point, it is imperative to stop and ensure that the basic
@@ -75,7 +46,7 @@ unset GCC_FIXED</userinput></screen>
     expected. To perform a sanity check, run the following commands:</para>
 
 <screen><userinput>echo 'main(){}' &gt; dummy.c
-cc dummy.c
+$LFS_TGT-gcc -B/tools/lib dummy.c
 readelf -l a.out | grep ': /tools'</userinput></screen>
 
     <para>If everything is working correctly, there should be no errors,
@@ -91,17 +62,7 @@ readelf -l a.out | grep ': /tools'</userinput></screen>
     <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. First, perform the sanity check again, using
-    <command>gcc</command> instead of <command>cc</command>. If this works,
-    then the <filename class="symlink">/tools/bin/cc</filename> symlink is
-    missing. Revisit <xref linkend="ch-tools-gcc-pass1" role=","/> and install
-    the symlink. Next, ensure that the <envar>PATH</envar> is correct. This
-    can be checked by running <command>echo $PATH</command> and verifying that
-    <filename class="directory">/tools/bin</filename> is at the head of the
-    list. If the <envar>PATH</envar> is wrong it could mean that you are not
-    logged in as user <systemitem class="username">lfs</systemitem> or that
-    something went wrong back in <xref linkend="ch-tools-settingenviron"
-    role="."/> Another option is that something may have gone wrong with the
+    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>
 
@@ -111,9 +72,9 @@ readelf -l a.out | grep ': /tools'</userinput></screen>
 
   </caution>
 
-  <note><para>Building Tcl in the next section will serve as an additional check that
-  the toolchain has been built properly.  If Tcl fails to build, it is an
-  indication that something has gone wrong with the Binutils, GCC, or Glibc
-  installation, but not with Tcl itself.</para></note>
+  <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>
 
 </sect1>