6.14.1. Installation of GCC
Apply a sed
substitution that will suppress the installation of libiberty.a
. The version of libiberty.a
provided by Binutils will be used
instead:
sed -i 's/install_to_$(INSTALL_DEST) //' libiberty/Makefile.in
The bootstrap build performed in Section 5.5, “GCC-4.3.2 -
Pass 1” built GCC with the -fomit-frame-pointer
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:
sed -i 's/^XCFLAGS =$/& -fomit-frame-pointer/' gcc/Makefile.in
The fixincludes
script is known to occasionally erroneously attempt to "fix" the
system headers installed so far. As the headers installed by
GCC-4.3.2 and Glibc-2.8-20080929 are known to not require fixing,
issue the following command to prevent the fixincludes script from running:
sed -i 's@\./fixinc\.sh@-c true@' gcc/Makefile.in
The GCC documentation recommends building GCC outside of the source
directory in a dedicated build directory:
mkdir -v ../gcc-build
cd ../gcc-build
Prepare GCC for compilation:
../gcc-4.3.2/configure --prefix=/usr \
--libexecdir=/usr/lib --enable-shared \
--enable-threads=posix --enable-__cxa_atexit \
--enable-clocale=gnu --enable-languages=c,c++ \
--disable-bootstrap
Note that for other languages, there are some prerequsites that are
not available. See the BLFS Book for instructions on how to build
all the GCC supported languages.
Compile the package:
make
Important
In this section, the test suite for GCC is considered critical.
Do not skip it under any circumstance.
Test the results, but do not stop at errors:
make -k check
To receive a summary of the test suite results, run:
../gcc-4.3.2/contrib/test_summary
For only the summaries, pipe the output through grep -A7 Summ
.
Results can be compared with those located at http://www.linuxfromscratch.org/lfs/build-logs/6.4/.
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 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20003).
Unless the test results are vastly different from those at the
above URL, it is safe to continue.
Install the package:
make install
Some packages expect the C preprocessor to be installed in the
/lib
directory. To support those
packages, create this symlink:
ln -sv ../usr/bin/cpp /lib
Many packages use the name cc to call the C compiler. To
satisfy those packages, create a symlink:
ln -sv gcc /usr/bin/cc
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 the same sanity checks as we did earlier in the
chapter:
echo 'main(){}' > dummy.c
cc dummy.c -v -Wl,--verbose &> dummy.log
readelf -l a.out | grep ': /lib'
If everything is working correctly, there should be no errors, and
the output of the last command will be (allowing for
platform-specific differences in dynamic linker name):
[Requesting program interpreter: /lib/ld-linux.so.2]
Now make sure that we're setup to use the correct startfiles:
grep -o '/usr/lib.*/crt[1in].*succeeded' dummy.log
If everything is working correctly, there should be no errors, and
the output of the last command will be:
/usr/lib/gcc/i686-pc-linux-gnu/4.3.2/../../../crt1.o succeeded
/usr/lib/gcc/i686-pc-linux-gnu/4.3.2/../../../crti.o succeeded
/usr/lib/gcc/i686-pc-linux-gnu/4.3.2/../../../crtn.o succeeded
Verify that the compiler is searching for the correct header files:
grep -B4 '^ /usr/include' dummy.log
This command should return successfully with the following output:
#include <...> search starts here:
/usr/local/include
/usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include
/usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include-fixed
/usr/include
Note
As of version 4.3.0, GCC now unconditionally installs the
limits.h
file into the private
include-fixed
directory, and that
directory is required to be in place.
Next, verify that the new linker is being used with the correct
search paths:
grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g'
If everything is working correctly, there should be no errors, and
the output of the last command will be:
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
If everything is working correctly, there should be no errors, and
the output of the last command will be:
attempt to open /lib/libc.so.6 succeeded
Lastly, make sure GCC is using the correct dynamic linker:
grep found dummy.log
If everything is working correctly, there should be no errors, and
the output of the last command will be (allowing for
platform-specific differences in dynamic linker name):
found ld-linux.so.2 at /lib/ld-linux.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. The most
likely reason is that something went wrong with the specs file
adjustment. Any issues will need to be resolved before continuing
on with the process.
Once everything is working correctly, clean up the test files:
rm -v dummy.c a.out dummy.log