Upgrade to gcc-4.0.1 (merge of gcc4 branch)

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

1 files changed, 48 insertions, 31 deletions

diff --git a/chapter05/gcc-pass2.xml b/chapter05/gcc-pass2.xml
index 78118cc60..7e1a1d29d 100644
--- a/chapter05/gcc-pass2.xml
+++ b/chapter05/gcc-pass2.xml
@@ -58,36 +58,50 @@ Binutils until this issue is resolved. Please consult the LFS FAQ at <ulink
 url="&lfs-root;/lfs/faq.html#no-ptys"/> for more information on how to get PTYs
 working.</para>
 
-<para>First correct a known problem and make an essential adjustment:</para>
-
-<screen><userinput>patch -Np1 -i ../&gcc-no_fixincludes-patch;
-patch -Np1 -i ../&gcc-specs-patch;</userinput></screen>
-
-<para>The first patch disables the GCC <command>fixincludes</command>
-script. This was briefly mentioned earlier, but a more in-depth
-explanation of the fixincludes process is warranted here. Under normal
-circumstances, the GCC <command>fixincludes</command> script scans the
-system for header files that need to be fixed. It might find that some
-Glibc header files on the host system need to be fixed, and will fix
-them and put them in the GCC private include directory. In <xref
-linkend="chapter-building-system"/>, after the newer Glibc has been
-installed, this private include directory will be searched before the
-system include directory.  This may result in GCC finding the fixed
-headers from the host system, which most likely will not match the
-Glibc version used for the LFS system.</para>
-
-<para>The second patch changes GCC's default location of the dynamic
-linker (typically <filename class="libraryfile">ld-linux.so.2</filename>). It also removes
-<filename class="directory">/usr/include</filename> from GCC's include
-search path. Patching 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 final (and temporary)
-binaries created during the build will link against the new
+<para>Under normal circumstances, the GCC <command>fixincludes</command> script
+scans the system for header files that need to be fixed (they may contain syntax
+errors, for example).  The script might find that some Glibc header files on the
+host system need to be fixed, so fixes them and puts them in the GCC private
+include directory. In <xref linkend="chapter-building-system"/>, after the
+newer Glibc has been installed, this private include directory will be searched
+before the system include directory.  This may result in GCC finding the fixed
+headers from the host system, which most likely will not match the Glibc version
+used for the LFS system.</para>
+
+<para>The following command adjusts where the GCC <command>fixincludes</command>
+script searches for headers, so that it fixes only the new headers under
+<filename class="directory">/tools</filename>, not the ones from your host
+system.</para>
+
+<screen><userinput>cp gcc/Makefile.in{,.orig} &amp;&amp;
+sed 's@\(^NATIVE_SYSTEM_HEADER_DIR =\).*@\1 /tools/include@g' \
+      gcc/Makefile.in.orig &gt; gcc/Makefile.in</userinput></screen>
+
+<para>The bootstrap build performed in <xref linkend="ch-tools-gcc-pass1"/>
+built GCC with the <option>-fomit-frame-pointer</option> compiler flag.
+Non-bootstrap builds omit this flag by default, so apply the following
+<command>sed</command> to use it in order to ensure consistent compiler builds.
+</para>
+
+<screen><userinput>cp gcc/Makefile.in{,.tmp} &amp;&amp;
+sed 's/^XCFLAGS =$/&amp; -fomit-frame-pointer/' gcc/Makefile.in.tmp \
+	&gt; gcc/Makefile.in</userinput></screen>
+
+<para>Apply the following patch to change the location of GCC's default dynamic
+linker (typically <filename class="libraryfile">ld-linux.so.2</filename>):</para>
+
+<screen><userinput>patch -Np1 -i ../&gcc-specs-patch;</userinput></screen>
+
+<para>The above patch also removes
+<filename class="directory">/usr/include</filename> from GCC's include search
+path. Patching 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.</para>
 
-<important><para>The above patches are critical in ensuring a
+<important><para>The above patch is critical in ensuring a
 successful overall build. Do not forget to apply
-them.</para></important>
+it.</para></important>
 
 <para>Create a separate build directory again:</para>
 
@@ -180,10 +194,13 @@ failures. To receive a summary of the test suite results, run:</para>
 <para>Results can be compared with those located at <ulink
 url="&test-results;"/>.</para>
 
-<para>A few unexpected failures cannot always be avoided. The
-GCC developers are usually aware of these issues, but have not
-resolved them yet. Unless the test results are vastly different from
-those at the above URL, it is safe to continue.</para>
+<para>A few unexpected failures cannot always be avoided. The GCC developers are
+usually aware of these issues, but have not resolved them yet. In particular,
+the <filename class="libraryfile">libmudflap</filename> tests are known be
+particularly problematic as a result of a bug in GCC (<ulink
+url="http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20003"/>).  Unless the test
+results are vastly different from those at the above URL, it is safe to
+continue.</para>
 
 <para>Install the package:</para>