%general-entities; ]> gcc &gcc-version;

&gcc-url;

GCC If building on x86_64, change the default directory name for 64-bit libraries to lib: case $(uname -m) in x86_64) sed -e '/m64=/s/lib64/lib/' \ -i.orig gcc/config/i386/t-linux64 ;; esac The GCC documentation recommends building GCC in a dedicated build directory: mkdir -v build cd build Prepare GCC for compilation: ../configure --prefix=/usr \ LD=ld \ --enable-languages=c,c++ \ --enable-default-pie \ --enable-default-ssp \ --disable-multilib \ --disable-bootstrap \ --with-system-zlib GCC supports seven different computer languages, but the prerequisites for most of them have not yet been installed. See the BLFS Book GCC page for instructions on how to build all of GCC's supported languages. LD=ld This parameter makes the configure script use the ld program installed by the Binutils package built earlier in this chapter, rather than the cross-built version which would otherwise be used. --with-system-zlib This switch tells GCC to link to the system installed copy of the Zlib library, rather than its own internal copy. PIE (position-independent executables) are binary programs that can be loaded anywhere in memory. Without PIE, the security feature named ASLR (Address Space Layout Randomization) can be applied for the shared libraries, but not for the executables themselves. Enabling PIE allows ASLR for the executables in addition to the shared libraries, and mitigates some attacks based on fixed addresses of sensitive code or data in the executables. SSP (Stack Smashing Protection) is a technique to ensure that the parameter stack is not corrupted. Stack corruption can, for example, alter the return address of a subroutine, thus transferring control to some dangerous code (existing in the program or shared libraries, or injected by the attacker somehow). Compile the package: make In this section, the test suite for GCC is considered important, but it takes a long time. First-time builders are encouraged to run the test suite. The time to run the tests can be reduced significantly by adding -jx to the make -k check command below, where x is the number of CPU cores on your system. One set of tests in the GCC test suite is known to exhaust the default stack, so increase the stack size prior to running the tests: ulimit -s 32768 Test the results as a non-privileged user, but do not stop at errors: chown -Rv tester . su tester -c "PATH=$PATH make -k check" To extract a summary of the test suite results, run: ../contrib/test_summary To filter out only the summaries, pipe the output through grep -A7 Summ. Results can be compared with those located at and . Eleven tests in the i386 test suite for the gcc compiler are known to FAIL. It's because the test files do not account for the --enable-default-pie option. Four tests related to PR100400 may be reported as both XPASS and FAIL when testing the g++ compiler; the test file is not well written. A few unexpected failures cannot always be avoided. The GCC developers are usually aware of these issues, but have not resolved them yet. Unless the test results are vastly different from those at the above URL, it is safe to continue. Install the package: make install The GCC build directory is owned by tester now, and the ownership of the installed header directory (and its content) is incorrect. Change the ownership to the root user and group: chown -v -R root:root \ /usr/lib/gcc/$(gcc -dumpmachine)/&gcc-version;/include{,-fixed} Create a symlink required by the FHS for "historical" reasons. ln -svr /usr/bin/cpp /usr/lib Add a compatibility symlink to enable building programs with Link Time Optimization (LTO): ln -sfv ../../libexec/gcc/$(gcc -dumpmachine)/&gcc-version;/liblto_plugin.so \ /usr/lib/bfd-plugins/ Now that our final toolchain is in place, it is important to again ensure that compiling and linking will work as expected. We do this by performing some sanity checks: echo 'int main(){}' > dummy.c cc dummy.c -v -Wl,--verbose &> dummy.log readelf -l a.out | grep ': /lib' There should be no errors, and the output of the last command will be (allowing for platform-specific differences in the dynamic linker name): [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2] Now make sure that we're set up to use the correct start files: grep -E -o '/usr/lib.*/S?crt[1in].*succeeded' dummy.log The output of the last command should be: /usr/lib/gcc/x86_64-pc-linux-gnu/&gcc-version;/../../../../lib/Scrt1.o succeeded /usr/lib/gcc/x86_64-pc-linux-gnu/&gcc-version;/../../../../lib/crti.o succeeded /usr/lib/gcc/x86_64-pc-linux-gnu/&gcc-version;/../../../../lib/crtn.o succeeded Depending on your machine architecture, the above may differ slightly. The difference will be the name of the directory after /usr/lib/gcc. The important thing to look for here is that gcc has found all three crt*.o files under the /usr/lib directory. Verify that the compiler is searching for the correct header files: grep -B4 '^ /usr/include' dummy.log This command should return the following output: #include <...> search starts here: /usr/lib/gcc/x86_64-pc-linux-gnu/&gcc-version;/include /usr/local/include /usr/lib/gcc/x86_64-pc-linux-gnu/&gcc-version;/include-fixed /usr/include Again, the directory named after your target triplet may be different than the above, depending on your system architecture. Next, verify that the new linker is being used with the correct search paths: grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g' References to paths that have components with '-linux-gnu' should be ignored, but otherwise the output of the last command should be: SEARCH_DIR("/usr/x86_64-pc-linux-gnu/lib64") SEARCH_DIR("/usr/local/lib64") SEARCH_DIR("/lib64") SEARCH_DIR("/usr/lib64") SEARCH_DIR("/usr/x86_64-pc-linux-gnu/lib") SEARCH_DIR("/usr/local/lib") SEARCH_DIR("/lib") SEARCH_DIR("/usr/lib"); A 32-bit system may use a few other directories. For example, here is the output from an i686 machine: SEARCH_DIR("/usr/i686-pc-linux-gnu/lib32") SEARCH_DIR("/usr/local/lib32") SEARCH_DIR("/lib32") SEARCH_DIR("/usr/lib32") SEARCH_DIR("/usr/i686-pc-linux-gnu/lib") SEARCH_DIR("/usr/local/lib") SEARCH_DIR("/lib") SEARCH_DIR("/usr/lib"); Next make sure that we're using the correct libc: grep "/lib.*/libc.so.6 " dummy.log The output of the last command should be: attempt to open /usr/lib/libc.so.6 succeeded Make sure GCC is using the correct dynamic linker: grep found dummy.log The output of the last command should be (allowing for platform-specific differences in dynamic linker name): found ld-linux-x86-64.so.2 at /usr/lib/ld-linux-x86-64.so.2 If the output does not appear as shown above or is not received at all, then something is seriously wrong. Investigate and retrace the steps to find out where the problem is and correct it. Any issues should be resolved before continuing with the process. Once everything is working correctly, clean up the test files: rm -v dummy.c a.out dummy.log Finally, move a misplaced file: mkdir -pv /usr/share/gdb/auto-load/usr/lib mv -v /usr/lib/*gdb.py /usr/share/gdb/auto-load/usr/lib Installed programs Installed libraries Installed directories c++, cc (link to gcc), cpp, g++, gcc, gcc-ar, gcc-nm, gcc-ranlib, gcov, gcov-dump, gcov-tool, and lto-dump libasan.{a,so}, libatomic.{a,so}, libcc1.so, libgcc.a, libgcc_eh.a, libgcc_s.so, libgcov.a, libgomp.{a,so}, libitm.{a,so}, liblsan.{a,so}, liblto_plugin.so, libquadmath.{a,so}, libssp.{a,so}, libssp_nonshared.a, libstdc++.{a,so}, libstdc++fs.a, libsupc++.a, libtsan.{a,so}, and libubsan.{a,so} /usr/include/c++, /usr/lib/gcc, /usr/libexec/gcc, and /usr/share/gcc-&gcc-version; Short Descriptions c++ The C++ compiler c++ cc The C compiler cc cpp The C preprocessor; it is used by the compiler to expand the #include, #define, and similar directives in the source files cpp g++ The C++ compiler g++ gcc The C compiler gcc gcc-ar A wrapper around ar that adds a plugin to the command line. This program is only used to add "link time optimization" and is not useful with the default build options. gc-ar gcc-nm A wrapper around nm that adds a plugin to the command line. This program is only used to add "link time optimization" and is not useful with the default build options. gc-nm gcc-ranlib A wrapper around ranlib that adds a plugin to the command line. This program is only used to add "link time optimization" and is not useful with the default build options. gc-ranlib gcov A coverage testing tool; it is used to analyze programs to determine where optimizations will have the greatest effect gcov gcov-dump Offline gcda and gcno profile dump tool gcov-dump gcov-tool Offline gcda profile processing tool gcov-tool lto-dump Tool for dumping object files produced by GCC with LTO enabled lto-dump libasan The Address Sanitizer runtime library libasan libatomic GCC atomic built-in runtime library libatomic libcc1 The C preprocessing library libcc1 libgcc Contains run-time support for gcc libgcc libgcov This library is linked into a program when GCC is instructed to enable profiling libgcov libgomp GNU implementation of the OpenMP API for multi-platform shared-memory parallel programming in C/C++ and Fortran libgomp libitm The GNU transactional memory library libitm liblsan The Leak Sanitizer runtime library liblsan liblto_plugin GCC's LTO plugin allows Binutils to process object files produced by GCC with LTO enabled liblto_plugin libquadmath GCC Quad Precision Math Library API libquadmath libssp Contains routines supporting GCC's stack-smashing protection functionality. Normally it is not used, because Glibc also provides those routines. libssp libstdc++ The standard C++ library libstdc++ libstdc++fs ISO/IEC TS 18822:2015 Filesystem library libstdc++fs libsupc++ Provides supporting routines for the C++ programming language libsupc++ libtsan The Thread Sanitizer runtime library libtsan libubsan The Undefined Behavior Sanitizer runtime library libubsan