%general-entities; ]> gcc &gcc-version;
&gcc-url;
GCC-&gcc-version; - Pass 2 GCC tools, pass 2 <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="../chapter06/gcc.xml" xpointer="xpointer(/sect1/sect2[1]/para[1])"/> <segmentedlist> <segtitle>&buildtime;</segtitle> <segtitle>&diskspace;</segtitle> <seglistitem> <seg>&gcc-ch5p2-sbu;</seg> <seg>&gcc-ch5p2-du;</seg> </seglistitem> </segmentedlist> </sect2> <sect2 role="installation"> <title>Re-installation of 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. As previously explained in , under normal circumstances the GCC fixincludes script is run in order to fix potentially broken header files. As GCC-&gcc-version; and Glibc-&glibc-version; have already been installed at this point, and their respective header files are known to not require fixing, the fixincludes script is not required. As mentioned previously, the script may in fact pollute the build environment by installing fixed headers from the host system into GCC's private include directory. The running of the fixincludes script can be suppressed by issuing the following commands: cp -v gcc/Makefile.in{,.orig} sed 's@\./fixinc\.sh@-c true@' 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 The following command will change the location of GCC's default dynamic linker to use the one we installed in /tools. It also removes /usr/include from GCC's include search path. Doing this 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. Issue: for file in $(find gcc/config -name linux64.h -o -name linux.h) do cp -uv $file{,.orig} sed -e 's@/lib\(64\)\?\(32\)\?/ld@/tools&@g' \ -e 's@/usr@/tools@g' $file.orig > $file echo " #undef STANDARD_INCLUDE_DIR #define STANDARD_INCLUDE_DIR 0" >> $file touch $file.orig done In case the above seems hard to follow, let's break it down a bit. First we find all the files under the gcc/config directory that are named either linux.h or linux64.h. For each file found, we copy it to a file of the same name but with an added suffix of .orig. Then the first sed expression prepends /tools to every instance of /lib/ld, /lib64/ld or /lib32/ld, while the second one replaces hard-coded instances of /usr. Then we add our define statements which alter the include search path to the end of the file. Finally, we use touch to update the timestamp on the copied files. When used in conjunction with cp -u, this prevents unexpected changes to the original files in case the command is inadvertently run twice. As in the first build of GCC it requires the GMP and MPFR packages. Unpack the tarballs and move them into the required directory names: tar -jxf ../mpfr-&mpfr-version;.tar.bz2 mv mpfr-&mpfr-version; mpfr tar -jxf ../gmp-&gmp-version;.tar.bz2 mv gmp-&gmp-version; gmp 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 \ --with-local-prefix=/tools --enable-clocale=gnu \ --enable-shared --enable-threads=posix \ --enable-__cxa_atexit --enable-languages=c,c++ \ --disable-libstdcxx-pch --disable-bootstrap 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. --disable-bootstrap Bootstrapping the compiler is now the default for GCC. However, our build method should provide us with a solid compiler without the need to bootstrap each time. Compile the package: make 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. For a discussion of test failures that are of particular importance, please see Install the package: make install <para>Details on this package are located in <xref linkend="contents-gcc" role="."/></para> </sect2> </sect1>