6.15.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
As in Section 5.10, “GCC-4.4.1
- Pass 2”, apply the following sed to force the build to use the
-fomit-frame-pointer
compiler flag in
order to ensure consistent compiler builds:
case `uname -m` in
i?86) sed -i 's/^T_CFLAGS =$/& -fomit-frame-pointer/' \
gcc/Makefile.in ;;
esac
The fixincludes
script is known to occasionally erroneously attempt to "fix" the
system headers installed so far. As the headers up to this point
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.4.1/configure --prefix=/usr \
--libexecdir=/usr/lib --enable-shared \
--enable-threads=posix --enable-__cxa_atexit \
--enable-clocale=gnu --enable-languages=c,c++ \
--disable-multilib --disable-bootstrap
Note that for other languages, there are some prerequisites 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.4.1/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.5/
and http://gcc.gnu.org/ml/gcc-testresults/.
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.4.1/../../../crt1.o succeeded
/usr/lib/gcc/i686-pc-linux-gnu/4.4.1/../../../crti.o succeeded
/usr/lib/gcc/i686-pc-linux-gnu/4.4.1/../../../crtn.o succeeded
Depending on your machine architecture, the above may differ
slightly, the difference usually being the name of the directory
after /usr/lib/gcc
. If your machine
is a 64-bit system, you may also see a directory named lib64
towards the end of the string. 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 successfully with the following output:
#include <...> search starts here:
/usr/local/include
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.1/include
/usr/lib/gcc/i686-pc-linux-gnu/4.4.1/include-fixed
/usr/include
Again, note that the directory named after your target triplet may
be different than the above, depending on your architecture.
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 (allowing for platform-specific
target triplets) will be:
SEARCH_DIR("/usr/i686-pc-linux-gnu/lib")
SEARCH_DIR("/usr/local/lib")
SEARCH_DIR("/lib")
SEARCH_DIR("/usr/lib");
A 64-bit system may see a few more directories. For example, here
is the output from an x86_64 machine:
SEARCH_DIR("/usr/x86_64-unknown-linux-gnu/lib64")
SEARCH_DIR("/usr/local/lib64")
SEARCH_DIR("/lib64")
SEARCH_DIR("/usr/lib64")
SEARCH_DIR("/usr/x86_64-unknown-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 (allowing for a lib64 directory on
64-bit hosts) 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 and a lib64
directory on 64-bit hosts):
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