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

4 files changed, 78 insertions, 43 deletions

diff --git a/chapter05/adjusting.xml b/chapter05/adjusting.xml
index 3f5ff2958..1991bd36d 100644
--- a/chapter05/adjusting.xml
+++ b/chapter05/adjusting.xml
@@ -31,14 +31,16 @@ second pass of Binutils is installed later.</para></note>
 <para>Now that the adjusted linker is installed, the Binutils build and source
 directories should be removed.</para>
 
-<para>The next task is to amend the GCC specs file so that it points
-to the new dynamic linker. A simple sed script will accomplish this:</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
+dynamic linker that GCC will use:</para>
 
 <!-- Ampersands are needed to allow copy and paste -->
 
-<screen><userinput>SPECFILE=`gcc -print-file-name=specs` &amp;&amp;
-sed 's@ /lib/ld-linux.so.2@ /tools/lib/ld-linux.so.2@g' \
-    $SPECFILE &gt; tempspecfile &amp;&amp;
+<screen><userinput>SPECFILE=`dirname $(gcc -print-libgcc-file-name)`/specs &amp;&amp;
+gcc -dumpspecs > $SPECFILE &amp;&amp;
+sed 's@^/lib/ld-linux.so.2@/tools&amp;@g' $SPECFILE &gt; tempspecfile &amp;&amp;
 mv -f tempspecfile $SPECFILE &amp;&amp;
 unset SPECFILE</userinput></screen>
 
@@ -59,14 +61,16 @@ dynamic linker in the above commands. Refer back to <xref
 linkend="ch-tools-toolchaintechnotes" role=","/> if
 necessary.</para></important>
 
-<para>There is a possibility that some include files from the host
-system have found their way into GCC's private include dir. This can
-happen as a result of GCC's <quote>fixincludes</quote> process, which runs as part
-of the GCC build. This is explained in more detail later in this
-chapter. Run the following command to eliminate this
-possibility:</para>
+<para>There is a possibility that some header files from the host system have
+found their way into GCC's private include dir. This can happen as a result of
+GCC's <quote>fixincludes</quote> process, which runs as part of the GCC build.
+This is explained in more detail later in this chapter. Run the following commands to remove those header files (you may find it easier to copy and paste these commands, rather than typing them by hand, due to their length):</para>
 
-<screen><userinput>rm -f /tools/lib/gcc/*/*/include/{pthread.h,bits/sigthread.h}</userinput></screen>
+<!-- && used to ease copy and pasting -->
+<screen><userinput>GCC_INCLUDEDIR=`dirname $(gcc -print-libgcc-file-name)`/include &amp;&amp;
+find ${GCC_INCLUDEDIR}/* -maxdepth 0 -xtype d -exec rm -rf '{}' \; &amp;&amp;
+rm -f `grep -l "DO NOT EDIT THIS FILE" ${GCC_INCLUDEDIR}/*` &amp;&amp;
+unset GCC_INCLUDEDIR</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
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>
 
diff --git a/chapter05/glibc.xml b/chapter05/glibc.xml
index 068fef71a..f0119bbaf 100644
--- a/chapter05/glibc.xml
+++ b/chapter05/glibc.xml
@@ -45,6 +45,15 @@ The problem has been determined to be with the tests themselves, not with the C
 
 <screen><userinput>patch -Np1 -i ../&glibc-testfix-patch;</userinput></screen>
 
+<para>Apply the following patches to enable Glibc to compile with
+GCC-&gcc-version;:</para>
+
+
+<screen><userinput>patch -Np1 -i ../&glibc-gcc4_symbols-patch;
+patch -Np1 -i ../&glibc-gcc4_string-patch;
+patch -Np1 -i ../&glibc-gcc4_elf-patch;
+patch -Np1 -i ../&glibc-gcc4_iconvdata-patch;</userinput></screen>
+
 <para>The Glibc documentation recommends building Glibc outside of the source
 directory in a dedicated build directory:</para>
 
diff --git a/chapter05/tar.xml b/chapter05/tar.xml
index 6c18c6111..15c522c0d 100644
--- a/chapter05/tar.xml
+++ b/chapter05/tar.xml
@@ -29,6 +29,11 @@
 <sect2 role="installation">
 <title>Installation of Tar</title>
 
+<para>If you wish to run the test suite, apply the following patch to fix
+some issues with GCC-&gcc-version;:</para>
+
+<screen><userinput>patch -Np1 -i ../&tar-gcc4_fix-patch;</userinput></screen>
+
 <para>Prepare Tar for compilation:</para>
 
 <screen><userinput>./configure --prefix=/tools</userinput></screen>