source: chapter05/gcc-pass2.xml@ 32a531e

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN" "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [
  <!ENTITY % general-entities SYSTEM "../general.ent">
  %general-entities;
]>
<sect1 id="ch-tools-gcc-pass2">
<title>GCC-&gcc-version; - Pass 2</title>
<?dbhtml filename="gcc-pass2.html"?>

<indexterm zone="ch-tools-gcc-pass2">
<primary sortas="a-GCC">GCC</primary>
<secondary>tools, pass 2</secondary></indexterm>

<screen>&buildtime; 11.0 SBU
&diskspace; 274 MB</screen>


<sect2>
<title>Re-installation of GCC</title>

<para>The tools required to test GCC and Binutils are installed now: Tcl,
Expect and DejaGnu. Therefore we can now rebuild GCC and Binutils, linking
them against the new Glibc, and test them properly (if running the test suites
in this chapter). One thing to note, however, is that these test suites are
highly dependent on properly functioning pseudo terminals (PTYs) which are
provided by your host. These days, PTYs are most commonly implemented via the
<emphasis>devpts</emphasis> file system. You can quickly check if your host
system is set up correctly in this regard by performing a simple test:</para>

<screen><userinput>expect -c "spawn ls"</userinput></screen>

<para>The response might be:</para>

<blockquote><screen>The system has no more ptys.  Ask your system administrator to create more.</screen></blockquote>

<para>If you receive the above message, your host doesn't have its PTYs set up
properly. In this case there is no point in running the test suites for GCC
and Binutils until you are able to resolve the issue. You can consult the LFS
Wiki at <ulink url="&wiki-root;"/> for more information on how to get PTYs
working.</para>

<para>This time we will build both the C and the C++ compilers, so you'll have
to unpack both the core and the g++ tarballs (and testsuite too, if you want to
run the tests). Unpacking them in your working directory, they will all unfold
into a single <filename>gcc-&gcc-version;/</filename> subdirectory.</para>

<para>First correct a problem and make an essential adjustment:</para>

<screen><userinput>patch -Np1 -i ../gcc-&gcc-version;-no-fixincludes-1.patch
patch -Np1 -i ../gcc-&gcc-version;-specs-1.patch</userinput></screen>

<para>The first patch disables the GCC <quote>fixincludes</quote> script. We
mentioned this briefly earlier, but a slightly more in-depth explanation of
the fixincludes process is warranted here. Under normal circumstances, the GCC
fixincludes script scans your system for header files that need to be fixed. It
might find that some Glibc header files on your host system need to be fixed,
fix them and put them in the GCC private include directory. Then, later on in
<xref linkend="chapter-building-system"/>, after we've installed the newer
Glibc, this private include directory would be searched before the system
include directory, resulting in GCC finding the fixed headers from the host
system, which would most likely not match the Glibc version actually used for
the LFS system.</para>

<para>The second patch changes GCC's default location of the dynamic linker
(typically <filename>ld-linux.so.2</filename>). It also removes
<filename class="directory">/usr/include</filename> from GCC's include search
path. Patching now rather than adjusting the specs file after installation
ensures that our new dynamic linker gets used during the actual build of GCC.
That is, all the final (and temporary) binaries created during the build will
link against the new Glibc.</para>

<important><para>The above patches are <emphasis>critical</emphasis> in ensuring
a successful overall build. Do not forget to apply them.</para></important>

<para>Create a separate build directory again:</para>

<screen><userinput>mkdir ../gcc-build
cd ../gcc-build</userinput></screen>

<para>Before starting to build GCC, remember to unset any environment
variables that override the default optimization flags.</para>

<para>Now prepare GCC for compilation:</para>

<screen><userinput>../gcc-&gcc-version;/configure --prefix=/tools \
    --libexecdir=/tools/lib --with-local-prefix=/tools \
    --enable-clocale=gnu --enable-shared --enable-threads=posix \
    --enable-__cxa_atexit --enable-languages=c,c++ \
    --disable-libstdcxx-pch</userinput></screen>

<para>The meaning of the new configure options:</para>

<itemizedlist>
<listitem><para><userinput>--enable-clocale=gnu</userinput>: This option
ensures the correct locale model is selected for the C++ libraries under all
circumstances. If the configure script finds the <emphasis>de_DE</emphasis>
locale installed, it will select the correct <emphasis>gnu</emphasis> locale
model. However, people who don't install the <emphasis>de_DE</emphasis> locale
would run the risk of building ABI incompatible C++ libraries due to the wrong
<emphasis>generic</emphasis> locale model being selected.</para></listitem>

<listitem><para><userinput>--enable-threads=posix</userinput>: This enables
C++ exception handling for multi-threaded code.</para></listitem>

<listitem><para><userinput>--enable-__cxa_atexit</userinput>: This option
allows use of __cxa_atexit, rather than atexit, to register C++ destructors for
local statics and global objects and 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.</para></listitem>

<listitem><para><userinput>--enable-languages=c,c++</userinput>: This option
ensures that both the C and C++ compilers are built.</para></listitem>

<listitem><para><userinput>--disable-libstdcxx-pch</userinput>: Don't build the
PCH (pre-compiled header) for libstdc++. It takes up a ton of space, and we
have no use for it.</para></listitem>
</itemizedlist>

<para>Compile the package:</para>

<screen><userinput>make</userinput></screen>

<para>There is no need to use the <emphasis>bootstrap</emphasis> target now,
as the compiler we're using to compile this GCC was built from the exact same
version of the GCC sources we used earlier.</para>

<para>Compilation is now complete. As mentioned earlier, we don't recommend
running the test suites for the temporary tools here in this chapter. If you
still want to run the GCC test suite anyway, the following command will do
so:</para>

<screen><userinput>make -k check</userinput></screen>

<para>The <emphasis>-k</emphasis> 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. To get
a summary of the test suite results, run this:</para>
 
<screen><userinput>../gcc-&gcc-version;/contrib/test_summary</userinput></screen>

<para>(For just the summaries, pipe the output through
<userinput>grep -A7 Summ</userinput>.)</para>

<para>You can compare your results to those posted to the gcc-testresults
mailing list for similar configurations to your own. For an example of how
current GCC-&gcc-version; should look on i686-pc-linux-gnu, see
<ulink url="http://gcc.gnu.org/ml/gcc-testresults/2004-04/msg00414.html"/>.</para>

<para>Having a few unexpected failures often cannot be avoided. The GCC
developers are usually aware of these, but haven't yet gotten around to fixing
them. In short, unless your results are vastly different from those at the above
URL, it is safe to continue.</para>

<para>And finally install the package:</para>

<screen><userinput>make install</userinput></screen>

<note><para>At this point it is strongly recommended to repeat the sanity check
we performed earlier in this chapter. Refer back to
<xref linkend="ch-tools-adjusting"/> and repeat the little test compilation. If
the result is wrong, then most likely you forgot to apply the above mentioned
GCC Specs patch.</para></note>

</sect2>

<sect2><title/>
<para>The details on this package are found in <xref linkend="contents-gcc"/>.</para>
</sect2>

</sect1>