Installing GCC-&gcc-version; - Pass 2 &buildtime; &gcc-time-tools-pass2; &diskspace; &gcc-compsize-tools-pass2; &aa-gcc-down; &aa-gcc-dep;    Re-installation of GCC The tools required to test GCC and Binutils are installed now: Tcl, Expect and DejaGnu. Therefore we can now rebuild GCC and Binutils, linking them against the new Glibc, and test them properly (if running the test suites in this chapter). 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. These days, PTYs are most commonly implemented via the devpts file system. You can quickly check if your host system is set up correctly in this regard by performing a simple test: expect -c "spawn ls" The response might be:
The system has no more ptys. Ask your system administrator to create more.
If you receive the above message, your host doesn't have its PTYs set up properly. 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 for more information on how to get PTYs working. This time we will build both the C and the C++ compilers, so you'll have to unpack both the core and the g++ tarballs (and testsuite too, if you want to run the tests). Unpacking them in your working directory, they will all unfold into a single &gcc-dir;/ subdirectory. First correct a problem and make an essential adjustment: patch -Np1 -i ../&gcc-nofixincludes-patch; patch -Np1 -i ../&gcc-specs-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 some 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 , 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 second patch changes GCC's default location of the dynamic linker (typically ld-linux.so.2). It also removes /usr/include 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. The above patches are critical in ensuring a successful overall build. Do not forget to apply them. 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 for compilation: ../&gcc-dir;/configure --prefix=/tools \     --with-local-prefix=/tools \     --enable-clocale=gnu --enable-shared \     --enable-threads=posix --enable-__cxa_atexit \     --enable-languages=c,c++ The meaning of the new configure options: --enable-clocale=gnu: This option ensures the correct locale model is selected for the C++ libraries under all circumstances. If the configure script finds the de_DE locale installed, it will select the correct gnu locale model. However, people who don't install the de_DE locale would run the risk of building ABI incompatible C++ libraries due to the wrong generic locale model being selected. --enable-threads=posix: This enables C++ exception handling for multi-threaded code. --enable-__cxa_atexit: This option allows use of __cxa_atexit, rather than atexit, to register C++ destructors for local statics and global objects and is essential for fully standards-compliant handling of destructors. It also affects the C++ ABI and therefore results in C++ shared libraries and C++ programs that are interoperable with other Linux distributions. --enable-languages=c,c++: This option ensures that both the C and C++ compilers are built. Compile the package: make There is no need to use the bootstrap target now, as the compiler we're using to compile this GCC was built from the exact same version of the GCC sources we used earlier. Compilation is now complete. As mentioned earlier, we don't recommend running the test suites for the temporary tools here in this chapter. If you still want to run the GCC test suite anyway, the following command will do so: 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-dir;/contrib/test_summary (For just the summaries, pipe the output through grep -A7 Summ.) 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-&gcc-version; should look on i686-pc-linux-gnu, see . Note that the results contain: * 1 XPASS (unexpected pass) for g++ * 1 FAIL (unexpected failure) for gcc * 24 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 24 unexpected passes for libstdc++ are due to the use of --enable-clocale=gnu. This option, which is the correct choice on Glibc-based systems of versions 2.2.5 and above, enables in the GNU C library a locale support that is superior to the otherwise selected generic model (which may be applicable if for instance you were using Newlibc, Sun-libc or whatever other libc). The libstdc++ test suite is apparently expecting the generic model, hence those tests are not always expected to pass. Having a few unexpected failures often cannot be avoided. The GCC developers are usually aware of these, but haven't yet gotten around to fixing them. In short, unless your results are vastly different from those at the above URL, it is safe to continue. And finally install the package: make install At this point it is strongly recommended to repeat the sanity check we performed earlier in this chapter. Refer back to and repeat the little test compilation. If the result is wrong, then most likely you forgot to apply the above mentioned GCC Specs patch.    The details on this package are found in .