8.26.1. Installation of GCC
At first, fix an issue breaking libasan.a building this package with Glibc-2.34
or later:
sed -e '/static.*SIGSTKSZ/d' \
-e 's/return kAltStackSize/return SIGSTKSZ * 4/' \
-i libsanitizer/sanitizer_common/sanitizer_posix_libcdep.cpp
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++ \
--disable-multilib \
--disable-bootstrap \
--with-system-zlib
Note that for other programming languages there are some
prerequisites that are not yet available. See the
BLFS Book GCC page for instructions on how to build all of
GCC's supported languages.
The meaning of the new configure parameters:
-
LD=ld
-
This parameter makes the configure script use the ld
installed by the binutils 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.
Compile the package:
make
![[Important]](../images/important.png)
Important
In this section, the test suite for GCC is considered important,
but it takes a long time. First time builders are encouraged to
not skip it. The time to run the tests can be reduced
significantly by adding -jx to the make command below where x is
the number of 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 receive a summary of the test suite results, run:
../contrib/test_summary
For only the summaries, pipe the output through grep -A7 Summ.
Results can be compared with those located at https://www.linuxfromscratch.org/lfs/build-logs/11.1/
and https://gcc.gnu.org/ml/gcc-testresults/.
Eight tests related to analyzer are known to fail.
One test named asan_test.C is known
to fail.
In libstdc++, one test named 49745.cc
is known to fail because the header dependencies in glibc have
changed.
In libstdc++, one numpunct test and six tests related to get_time
are known to fail. These are all because the locale definitions in
glibc have changed but libstdc++ does not currently support those
changes.
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 and remove an unneeded directory:
make install
rm -rf /usr/lib/gcc/$(gcc -dumpmachine)/11.2.0/include-fixed/bits/
The GCC build directory is owned by tester now and the ownership of the installed
header directory (and its content) will be incorrect. Change the
ownership to root user and group:
chown -v -R root:root \
/usr/lib/gcc/*linux-gnu/11.2.0/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)/11.2.0/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 setup to use the correct start files:
grep -o '/usr/lib.*/crt[1in].*succeeded' dummy.log
The output of the last command should be:
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../lib/crt1.o succeeded
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../lib/crti.o succeeded
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../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/11.2.0/include
/usr/local/include
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/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 see a few different 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
will need to 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