Details on this package are located in Section 6.12.2, “Contents of GCC.”
The GCC package contains the GNU compiler collection, which includes the C and C++ compilers.
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 http://www.linuxfromscratch.org//lfs/faq.html#no-ptys for more information on how to get PTYs working.
As previously explained in Section 5.7, “Adjusting the Toolchain”, under normal circumstances the GCC fixincludes script is run in order to fix potentially broken header files. As GCC-4.1.2 and Glibc-2.5.1 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 Section 5.4, “GCC-4.1.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:
cp -v gcc/Makefile.in{,.tmp} sed 's/^XCFLAGS =$/& -fomit-frame-pointer/' gcc/Makefile.in.tmp \ > gcc/Makefile.in
Apply the following patch to change the location of GCC's default
dynamic linker (typically ld-linux.so.2
):
patch -Np1 -i ../gcc-4.1.2-specs-1.patch
The above patch also removes /usr/include
from GCC's include search path.
Patching 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.
The above patch is critical in ensuring a successful overall build. Do not forget to apply it.
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-4.1.2/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
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.
Compile the package:
make
There is no need to use the bootstrap
target now because the
compiler being used to compile this GCC was built from the exact
same version of the GCC sources used earlier.
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 Section 6.12, “GCC-4.1.2.”
Install the package:
make install
At this point, it is imperative to stop and ensure that the basic functions (compiling and linking) of the new toolchain are working as expected. To perform a sanity check, run the following commands:
echo 'main(){}' > dummy.c cc dummy.c readelf -l a.out | grep ': /tools'
If everything is working correctly, there should be no errors, and the output of the last command will be of the form:
[Requesting program interpreter:
/tools/lib/ld-linux.so.2]
Note that /tools/lib
appears as the
prefix of the dynamic linker.
If the output is not shown as above or there was no output at
all, then something is wrong. Investigate and retrace the steps
to find out where the problem is and correct it. This issue must
be resolved before continuing on. First, perform the sanity check
again, using gcc
instead of cc. If
this works, then the /tools/bin/cc
symlink is missing. Revisit Section 5.4,
“GCC-4.1.2 - Pass 1,” and install the symlink.
Next, ensure that the PATH
is correct.
This can be checked by running echo
$PATH and verifying that /tools/bin
is at the head of the list. If the
PATH
is wrong it could mean that you
are not logged in as user lfs
or
that something went wrong back in Section 4.4,
“Setting Up the Environment.” Another option is
that something may have gone wrong with the specs file amendment
above. In this case, redo the specs file amendment, being careful
to copy-and-paste the commands.
Once all is well, clean up the test files:
rm -v dummy.c a.out
Details on this package are located in Section 6.12.2, “Contents of GCC.”