source: chapter05/gcc-pass2.xml@ b8dd57d6

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
  "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
  <!ENTITY % general-entities SYSTEM "../general.ent">
  %general-entities;
]>

<sect1 id="ch-tools-gcc-pass2" role="wrap">
  <?dbhtml filename="gcc-pass2.html"?>

  <title>GCC-&gcc-version; - Pass 2</title>

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

  <sect2 role="package">
    <title/>

    <xi:include xmlns:xi="http://www.w3.org/2003/XInclude"
    href="../chapter06/gcc.xml"
    xpointer="xpointer(/sect1/sect2[1]/para[1])"/>

    <segmentedlist>
      <segtitle>&buildtime;</segtitle>
      <segtitle>&diskspace;</segtitle>

      <seglistitem>
        <seg>&gcc-ch5p2-sbu;</seg>
        <seg>&gcc-ch5p2-du;</seg>
      </seglistitem>
    </segmentedlist>

  </sect2>

  <sect2 role="installation">
    <title>Re-installation of GCC</title>

    <para>The tools required to test GCC and Binutils&mdash;Tcl, Expect
    and DejaGNU&mdash;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
    <systemitem class="filesystem">devpts</systemitem> file system. Check
    to see if the host system is set up correctly in this regard by
    performing a quick test:</para>

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

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

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

    <para>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 <ulink url="&lfs-root;/lfs/faq.html#no-ptys"/> for more
    information on how to get PTYs working.</para>

    <para>As previously explained in <xref linkend="ch-tools-adjusting"/>,
    under normal circumstances the GCC <command>fixincludes</command> script
    is run in order to fix potentially broken header files. As GCC-&gcc-version;
    and Glibc-&glibc-version; have already been installed at this point, and
    their respective header files are known to not require fixing, the
    <command>fixincludes</command> 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 <command>fixincludes</command> script can
    be suppressed by issuing the following commands:</para>

<screen><userinput>cp -v gcc/Makefile.in{,.orig}
sed 's@\./fixinc\.sh@-c true@' gcc/Makefile.in.orig &gt; gcc/Makefile.in</userinput></screen>

    <para>The bootstrap build performed in <xref linkend="ch-tools-gcc-pass1"/>
    built GCC with the <option>-fomit-frame-pointer</option> compiler flag.
    Non-bootstrap builds omit this flag by default, so apply the following
    <command>sed</command> to use it in order to ensure consistent compiler
    builds:</para>

<screen><userinput>cp -v gcc/Makefile.in{,.tmp}
sed 's/^XCFLAGS =$/&amp; -fomit-frame-pointer/' gcc/Makefile.in.tmp \
  &gt; gcc/Makefile.in</userinput></screen>

    <para>The following command will change the location of GCC's default
    dynamic linker to use the one we installed in
    <filename class="directory">/tools</filename>. It also removes <filename
    class="directory">/usr/include</filename> from GCC's include search path.
    Doing this 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. Issue:</para>

<screen><userinput>for file in $(find gcc/config -name linux64.h -o -name linux.h)
do
  cp -uv $file{,.orig}
  sed -e 's@/lib\(64\)\?\(32\)\?/ld@/tools&amp;@g' \
  -e 's@/usr@/tools@g' $file.orig &gt; $file
  echo "
#undef STANDARD_INCLUDE_DIR
#define STANDARD_INCLUDE_DIR 0" &gt;&gt; $file
  touch $file.orig
done</userinput></screen> 

    <para>In case the above seems hard to follow, let's break it down a bit.
    First we find all the files under the gcc/config directory that are named
    either <filename>linux.h</filename> or <filename>linux64.h</filename>.
    For each file found, we copy it to a file of the same name but with an added
    suffix of <quote>.orig</quote>. Then the first sed expression prepends
    <quote>/tools</quote> to every instance of <quote>/lib/ld</quote>,
    <quote>/lib64/ld</quote> or <quote>/lib32/ld</quote>, while the second one
    replaces hard-coded instances of <quote>/usr</quote>. Then we add our define
    statments altering the include search path to the end of the file. Finally,
    we use <command>touch</command> to update the timestamp on the copied files.
    When used in conjunction with <command>cp -u</command>, this prevents unexpected
    changes to the original files in case the command is inadvertently run twice.
    </para>

    <para>Unsetting the multlib spec for GCC ensures that it
    won't attempt to link against libraries on the host:</para>

<screen><userinput>for file in $(find gcc/config -name t-linux64) ; do \
   cp -v $file{,.orig}
   sed '/MULTILIB_OSDIRNAMES/d' $file.orig &gt; $file
done</userinput></screen>

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

<screen><userinput>mkdir -v ../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>The --with-arch flag is only necessary for x86 machines.</para>

<screen><userinput>case $(uname -m) in
  x86) WITHARCH="--with-arch=i486" ;;
esac</userinput></screen>

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

<screen><userinput>../gcc-&gcc-version;/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 --disable-multilib \
    $WITHARCH
unset WITHARCH</userinput></screen>

    <variablelist>
      <title>The meaning of the new configure options:</title>

      <varlistentry>
        <term><parameter>--enable-clocale=gnu</parameter></term>
        <listitem>
          <para>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 gnu locale model. However, if the
          <emphasis>de_DE</emphasis> 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.</para>
        </listitem>
      </varlistentry>

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

      <varlistentry>
        <term><parameter>--enable-__cxa_atexit</parameter></term>
        <listitem>
          <para>This option allows use of <function>__cxa_atexit</function>,
          rather than <function>atexit</function>, 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.</para>
        </listitem>
      </varlistentry>

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

      <varlistentry>
        <term><parameter>--disable-libstdcxx-pch</parameter></term>
        <listitem>
          <para>Do not build the pre-compiled header (PCH) for
          <filename class="libraryfile">libstdc++</filename>. It takes up a
          lot of space, and we have no use for it.</para>
        </listitem>
      </varlistentry>

    </variablelist>

    <para>Compile the package:</para>

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

    <para>There is no need to use the <parameter>bootstrap</parameter> target
    now because the compiler being used to compile this GCC was built from
    the exact same version of the GCC sources used earlier.</para>

    <para>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:</para>

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

    <para>The <parameter>-k</parameter> 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.</para>

    <para>For a discussion of test failures that are of particular
    importance, please see <xref linkend="ch-system-gcc" role="."/></para>

    <para>Install the package:</para>

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

    <xi:include xmlns:xi="http://www.w3.org/2003/XInclude"
    href="adjusting.xml"
    xpointer="xpointer(/sect1/caution[1])"/>

  </sect2>

  <sect2 role="content">
    <title/>

    <para>Details on this package are located in
    <xref linkend="contents-gcc" role="."/></para>

  </sect2>

</sect1>