Ticket #2461: toolchain-v2.patch

chapter05/toolchaintechnotes.xml

@@ -99 +99 @@
   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>
+        /tools/i686-lfs-linux-gnu/bin/as
+checking what linker to use... /tools/i686-lfs-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
@@ -117 +117 @@
 
   <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
+  compiler is generally not an issue since Glibc will always use the compiler
+  relating to the <parameter>--host</parameter> parameter passed to its
+  configure script, e.g. <command>i686-lfs-linux-gnu-gcc</command>. 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
+  Note the use of <parameter>CC="i686-lfs-gnu-gcc"</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&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, 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:
+  <para>After the Glibc installation, 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 in ensuring
+  that searching and linking take place only within the <filename
+  class="directory">/tools</filename> prefix. 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 &lt;name of binary&gt; | 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