%general-entities; %patches-entities; ]> GCC-&gcc-version; - Pass 2 GCC tools, pass 2 <segmentedlist> <segtitle>&buildtime;</segtitle> <segtitle>&diskspace;</segtitle> <seglistitem><seg>11.0 SBU</seg><seg>292 MB</seg></seglistitem> </segmentedlist> <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="../chapter06/gcc.xml" xpointer="xpointer(/sect1/sect2[1]/segmentedlist[2])"/> </sect2> <sect2 role="installation"> <title>Re-installation of GCC This package is known to have issues when its default optimization flags (including the -march and -mcpu options) are changed. If any environment variables that override default optimizations have been defined, such as CFLAGS and CXXFLAGS, unset them when building GCC. The tools required to test GCC and Binutils—Tcl, Expect and DejaGNU—are installed now. GCC and Binutils can now be rebuilt, linking them against the new Glibc and testing them properly (if running the test suites in this chapter). Please note that these test suites are highly dependent on properly functioning PTYs which are provided by the host. PTYs are most commonly implemented via the devpts file system. Check to see if the host system is set up correctly in this regard by performing a quick test: expect -c "spawn ls" The response might be: The system has no more ptys. Ask your system administrator to create more. If the above message is received, the host does not have its PTYs set up properly. In this case, there is no point in running the test suites for GCC and Binutils until this issue is resolved. Please consult the LFS FAQ at for more information on how to get PTYs working. Under normal circumstances, the GCC fixincludes 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 , 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. The following command adjusts where the GCC fixincludes script searches for headers, so that it fixes only the new headers under /tools, not the ones from your host system. cp -v gcc/Makefile.in{,.orig} && sed 's@\(^NATIVE_SYSTEM_HEADER_DIR =\).*@\1 /tools/include@g' \ gcc/Makefile.in.orig > gcc/Makefile.in The bootstrap build performed in built GCC with the compiler flag. Non-bootstrap builds omit this flag by default, so apply the following sed to use it in order to ensure consistent compiler builds. cp -v gcc/Makefile.in{,.tmp} && sed 's/^XCFLAGS =$/& -fomit-frame-pointer/' gcc/Makefile.in.tmp \ > gcc/Makefile.in Apply the following patch to change the location of GCC's default dynamic linker (typically ld-linux.so.2): patch -Np1 -i ../&gcc-specs-patch; The above patch also removes /usr/include 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. The above patch is critical in ensuring a successful overall build. Do not forget to apply it. Create a separate build directory again: mkdir -v ../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-&gcc-version;/configure --prefix=/tools \ --libexecdir=/tools/lib --with-local-prefix=/tools \ --enable-clocale=gnu --enable-shared \ --enable-threads=posix --enable-__cxa_atexit \ --enable-languages=c,c++ --disable-libstdcxx-pch 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, if the de_DE locale is not installed, there is the risk of building Application Binary Interface (ABI)-incompatible C++ libraries because the incorrect generic locale model may be 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. This option 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. --disable-libstdcxx-pch Do not build the pre-compiled header (PCH) for libstdc++. It takes up a lot of space, and we have no use for it. Compile the package: make There is no need to use the bootstrap target now because the compiler being used to compile this GCC was built from the exact same version of the GCC sources used earlier. Compilation is now complete. As previously mentioned, running the test suites for the temporary tools compiled in this chapter is not mandatory. To run the GCC test suite anyway, use the following command: 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 receive a summary of the test suite results, run: ../gcc-&gcc-version;/contrib/test_summary For only the summaries, pipe the output through grep -A7 Summ. Results can be compared with those located at . 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 libmudflap tests are known be particularly problematic as a result of a bug in GCC (). Unless the test results are vastly different from those at the above URL, it is safe to continue. 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 test compilation. If the result is wrong, the most likely reason is that the GCC Specs patch was not properly applied. <para>Details on this package are located in <xref linkend="contents-gcc" role="."/></para> </sect2> </sect1>