Installing GCC-3.3.1 - Pass 2

Re-installation of GCC

The tools required to test GCC and Binutils are installed now (Expect, Tcl 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 the features supported by your host distribution. Most notably, a host distribution which does not properly support the devpts filesystem will cause most of these tests to fail.

Unpack all three GCC tarballs in one and the same working directory. They will all unfold into a single gcc-3.3.1/ subdir.

First correct one problem and make an essential adjustment:

patch -Np1 -i ../gcc-3.3.1-no_fixincludes-2.patch patch -Np1 -i ../gcc-3.3.1-specs-1.patch

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.

The last patch changes GCC's default location of the dynamic linker (ld). 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.

Create a separate build directory again:

mkdir ../gcc-build cd ../gcc-build

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

Now prepare GCC to be compiled:

../gcc-3.3.1/configure --prefix=/tools \ --with-local-prefix=/tools \ --enable-clocale=gnu --enable-shared \ --enable-threads=posix --enable-__cxa_atexit \ --enable-languages=c,c++

Compile the package:

make

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

Test the results:

make -k check

The -k 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:

../gcc-3.3.1/contrib/test_summary | less

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 http://gcc.gnu.org/ml/gcc-testresults/2003-08/msg01612.html.

Note that the results contain:

* 1 XPASS (unexpected pass) for g++
* 1 FAIL for g++
* 2 FAIL for gcc
* 26 XPASS's for libstdc++

The unexpected pass for g++ is due to the use of --enable-__cxa_atexit. 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.

The 26 unexpected passes for libstdc++ are due to the use of --enable-clocale=gnu, 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.

And finally install the package:

make install