lfs-book/chapter05/gcc-pass2-inst.xml

<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>

<sect2>
<title>Re-installation of GCC</title>

<para>The tools required to test GCC and Binutils are installed now (Tcl, Expect
and DejaGnu). We can continue on rebuilding GCC and Binutils, link them against
the new Glibc, and test them properly. One thing to note, however, is that these
test suites are highly dependent on properly functioning pseudo terminals (PTYs)
which are provided by your host distribution. These days, PTYs are most commonly
implemented via the <emphasis>devpts</emphasis> file system. You can quickly
check if your host system is set up correctly in this regard by performing a
simple test:</para>

<para><screen><userinput>expect -c "spawn ls"</userinput></screen></para>

<para>If you receive the message:</para>

<para><screen>The system has no more ptys.  Ask your system administrator to create more.</screen></para>

<para>Your host distribution is not set up for proper PTY operation. In this
case there is no point in running the test suites for GCC and Binutils until you
are able to resolve the issue. You can consult the LFS Wiki at
<ulink url="http://wiki.linuxfromscratch.org"/> for more information on how to
get PTYs working.</para>

<note><para>It's worth pointing out that the GCC test suite we run in this
section is considered not as critical as the one we run in Chapter 6.</para></note>

<para>Unpack all three GCC tarballs (-core, -g++, and -testsuite) in one and the same working directory.
They will all unfold into a single <filename>gcc-&gcc-version;/</filename>
subdir.</para>

<para>First correct one problem and make an essential adjustment:</para>

<para><screen><userinput>patch -Np1 -i ../gcc-&gcc-version;-no_fixincludes-2.patch
patch -Np1 -i ../gcc-&gcc-specs-version;.patch</userinput></screen></para>

<para>The first patch disables the GCC "fixincludes" script.  We mentioned this
briefly earlier, but a slightly more in-depth explanation of the fixincludes 
process is warranted here.  Under normal circumstances, the GCC fixincludes
script scans your system for header files that need to be fixed.  It might find
that the Glibc header files on your host system need to be fixed, fix them and
put them in the GCC private include directory.  Then, later on in Chapter 6,
after we've installed the newer Glibc, this private include directory would be
searched before the system include directory, resulting in GCC finding the
fixed headers from the host system, which would most likely not match the Glibc
version actually used for the LFS system.</para>

<para>The last patch changes GCC's default location of the dynamic linker
(typically <filename>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 our new dynamic linker gets used during the actual build of GCC.
That is, all the final (and temporary) binaries created during the build will
link against the new Glibc.</para>

<important><para>These patches are <emphasis>critical</emphasis> in ensuring a
successful overall build. Do not forget to apply them.</para></important>

<para>Create a separate build directory again:</para>

<para><screen><userinput>mkdir ../gcc-build
cd ../gcc-build</userinput></screen></para>

<para>Before starting to build GCC, remember to unset any environment
variables that override the default optimization flags.</para>

<para>Now prepare GCC to be compiled:</para>

<para><screen><userinput>../gcc-&gcc-version;/configure --prefix=/tools \
&nbsp;&nbsp;&nbsp;&nbsp;--with-local-prefix=/tools \
&nbsp;&nbsp;&nbsp;&nbsp;--enable-clocale=gnu --enable-shared \
&nbsp;&nbsp;&nbsp;&nbsp;--enable-threads=posix --enable-__cxa_atexit \
&nbsp;&nbsp;&nbsp;&nbsp;--enable-languages=c,c++</userinput></screen></para>

<para>Compile the package:</para>

<para><screen><userinput>make</userinput></screen></para>
<para>There is no need to use the <userinput>bootstrap</userinput> target now,
as the compiler we're using to compile this GCC has been built from the exact
same sources.</para>

<para>Test the results:</para>

<para><screen><userinput>make -k check</userinput></screen></para>

<para>The <userinput>-k</userinput> flag is used to make the test suite run
through to completion and not stop at the first failure. The GCC test suite is
very comprehensive and is almost guaranteed to generate a few failures. To get
a summary of the test suite results, run this:</para>
 
<para><screen><userinput>../gcc-&gcc-version;/contrib/test_summary | less</userinput></screen></para>

<para>You can compare your results to those posted to the gcc-testresults
mailing list for similar configurations to your own. For an example of how
current GCC-3.3.1 should look on i686-pc-linux-gnu, see
<ulink url="http://gcc.gnu.org/ml/gcc-testresults/2003-08/msg01612.html"/>.</para>

<para>Note that the results contain:</para>

<screen>* 1 XPASS (unexpected pass) for g++
* 1 FAIL for g++
* 2 FAIL for gcc
* 26 XPASS's for libstdc++</screen>
 
<para>The unexpected pass for g++ is due to the use of
<userinput>--enable-__cxa_atexit</userinput>. Apparently not all platforms
supported by GCC have support for "__cxa_atexit" in their C libraries, so this
test is not always expected to pass.</para>

<para>The 26 unexpected passes for libstdc++ are due to the use of
<userinput>--enable-clocale=gnu</userinput>, which is the correct choice on
Glibc-based systems of versions 2.2.5 and above. The underlying locale support
in the GNU C library is superior to that of the otherwise selected "generic"
model (which may be applicable if for instance you were using Newlibc, Sun-libc
or whatever libc). The libstdc++ test suite is apparently expecting the
"generic" model, hence those tests are not always expected to pass.</para>

<para>And finally install the package:</para>                                              

<para><screen><userinput>make install</userinput></screen></para>

</sect2>