Ignore:
Timestamp:
12/20/2004 05:23:16 PM (19 years ago)
Author:
Manuel Canales Esparcia <manuel@…>
Branches:
10.0, 10.0-rc1, 10.1, 10.1-rc1, 11.0, 11.0-rc1, 11.0-rc2, 11.0-rc3, 11.1, 11.1-rc1, 11.2, 11.2-rc1, 11.3, 11.3-rc1, 12.0, 12.0-rc1, 12.1, 12.1-rc1, 6.1, 6.1.1, 6.3, 6.4, 6.5, 6.6, 6.7, 6.8, 7.0, 7.1, 7.2, 7.3, 7.4, 7.5, 7.5-systemd, 7.6, 7.6-systemd, 7.7, 7.7-systemd, 7.8, 7.8-systemd, 7.9, 7.9-systemd, 8.0, 8.1, 8.2, 8.3, 8.4, 9.0, 9.1, arm, bdubbs/gcc13, ml-11.0, multilib, renodr/libudev-from-systemd, s6-init, trunk, xry111/arm64, xry111/arm64-12.0, xry111/clfs-ng, xry111/lfs-next, xry111/loongarch, xry111/loongarch-12.0, xry111/loongarch-12.1, xry111/mips64el, xry111/pip3, xry111/rust-wip-20221008, xry111/update-glibc
Children:
24244831
Parents:
6790655
Message:

Removed text in chapter 05 - second round.

git-svn-id: ​http://svn.linuxfromscratch.org/LFS/trunk/BOOK@4433 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689

File:
1 edited

Legend:

Unmodified
Added
Removed

  • chapter05/gcc-pass2.xml

    r6790655 rfba1478  
    2525<title>Re-installation of GCC</title>
    2626
    27 <para>The tools required to test GCC and Binutils are installed now: Tcl,
    28 Expect and DejaGNU. Therefore we can now rebuild GCC and Binutils, linking
    29 them against the new Glibc, and test them properly (if running the test suites
    30 in this chapter). One thing to note, however, is that these test suites are
    31 highly dependent on properly functioning pseudo terminals (PTYs) which are
    32 provided by your host. These days, PTYs are most commonly implemented via the
    33 <systemitem class="filesystem">devpts</systemitem> file system. You can quickly check if your host
    34 system is set up correctly in this regard by performing a simple test:</para>
     27<para>Check if there is PTYs for the test suites:</para>
    3528
    3629<screen><userinput>expect -c "spawn ls"</userinput></screen>
    3730
    38 <para>The response might be:</para>
    39 
    40 <blockquote><screen><computeroutput>The system has no more ptys.  Ask your system administrator to create more.</computeroutput></screen></blockquote>
    41 
    42 <para>If you receive the above message, your host doesn't have its PTYs set up
    43 properly. In this case there is no point in running the test suites for GCC
    44 and Binutils until you are able to resolve the issue. You can consult the LFS
    45 Wiki at <ulink url="&wiki-root;"/> for more information on how to get PTYs
    46 working.</para>
    47 
    48 <para>This time we will build both the C and the C++ compilers, so you'll have
    49 to unpack both the core and the g++ tarballs (and testsuite too, if you want to
    50 run the tests). Unpacking them in your working directory, they will all unfold
    51 into a single <filename class="directory">gcc-&gcc-version;/</filename> subdirectory.</para>
    52 
    53 <para>First correct a problem and make an essential adjustment:</para>
    54 
    5531<screen><userinput>patch -Np1 -i ../gcc-&gcc-version;-no_fixincludes-1.patch
    5632patch -Np1 -i ../gcc-&gcc-version;-specs-2.patch</userinput></screen>
    57 
    58 <para>The first patch disables the GCC <command>fixincludes</command> script. We
    59 mentioned this briefly earlier, but a slightly more in-depth explanation of
    60 the fixincludes process is warranted here. Under normal circumstances, the GCC
    61 <command>fixincludes</command> script scans your system for header files that need to be fixed. It
    62 might find that some Glibc header files on your host system need to be fixed,
    63 fix them and put them in the GCC private include directory. Then, later on in
    64 <xref linkend="chapter-building-system"/>, after we've installed the newer
    65 Glibc, this private include directory would be searched before the system
    66 include directory, resulting in GCC finding the fixed headers from the host
    67 system, which would most likely not match the Glibc version actually used for
    68 the LFS system.</para>
    69 
    70 <para>The second patch changes GCC's default location of the dynamic linker
    71 (typically <filename>ld-linux.so.2</filename>). It also removes
    72 <filename class="directory">/usr/include</filename> from GCC's include search
    73 path. Patching now rather than adjusting the specs file after installation
    74 ensures that our new dynamic linker gets used during the actual build of GCC.
    75 That is, all the final (and temporary) binaries created during the build will
    76 link against the new Glibc.</para>
    77 
    78 <important><para>The above patches are <emphasis>critical</emphasis> in ensuring
    79 a successful overall build. Do not forget to apply them.</para></important>
    8033
    8134<para>Create a separate build directory again:</para>
    … …  
    8336<screen><userinput>mkdir ../gcc-build
    8437cd ../gcc-build</userinput></screen>
    85 
    86 <para>Before starting to build GCC, remember to unset any environment
    87 variables that override the default optimization flags.</para>
    8838
    8939<para>Now prepare GCC for compilation:</para>
    … …  
    9545    --disable-libstdcxx-pch</userinput></screen>
    9646
    97 <para>The meaning of the new configure options:</para>
    98 
    99 <variablelist>
    100 <varlistentry>
    101 <term><parameter>--enable-clocale=gnu</parameter></term>
    102 <listitem><para>This option
    103 ensures the correct locale model is selected for the C++ libraries under all
    104 circumstances. If the configure script finds the <emphasis>de_DE</emphasis>
    105 locale installed, it will select the correct <emphasis>gnu</emphasis> locale
    106 model. However, people who don't install the <emphasis>de_DE</emphasis> locale
    107 would run the risk of building ABI incompatible C++ libraries due to the wrong
    108 <emphasis>generic</emphasis> locale model being selected.</para></listitem>
    109 </varlistentry>
    110 
    111 <varlistentry>
    112 <term><parameter>--enable-threads=posix</parameter></term>
    113 <listitem><para>This enables
    114 C++ exception handling for multi-threaded code.</para></listitem>
    115 </varlistentry>
    116 
    117 <varlistentry>
    118 <term><parameter>--enable-__cxa_atexit</parameter></term>
    119 <listitem><para>This option
    120 allows use of __cxa_atexit, rather than atexit, to register C++ destructors for
    121 local statics and global objects and is essential for fully standards-compliant
    122 handling of destructors. It also affects the C++ ABI and therefore results in
    123 C++ shared libraries and C++ programs that are interoperable with other Linux
    124 distributions.</para></listitem>
    125 </varlistentry>
    126 
    127 <varlistentry>
    128 <term><parameter>--enable-languages=c,c++</parameter></term>
    129 <listitem><para>This option
    130 ensures that both the C and C++ compilers are built.</para></listitem>
    131 </varlistentry>
    132 
    133 <varlistentry>
    134 <term><parameter>--disable-libstdcxx-pch</parameter></term>
    135 <listitem><para>Don't build the
    136 PCH (pre-compiled header) for libstdc++. It takes up a ton of space, and we
    137 have no use for it.</para></listitem>
    138 </varlistentry>
    139 </variablelist>
    140 
    14147<para>Compile the package:</para>
    14248
    14349<screen><userinput>make</userinput></screen>
    14450
    145 <para>There is no need to use the <parameter>bootstrap</parameter> target now,
    146 as the compiler we're using to compile this GCC was built from the exact same
    147 version of the GCC sources we used earlier.</para>
    148 
    149 <para>Compilation is now complete. As mentioned earlier, running the test suites
    150 for the temporary tools compiled in this chapter is not mandatory.  If you want to run the GCC test suite anyway, the following command will do so:</para>
    151 
    15251<screen><userinput>make -k check</userinput></screen>
    15352
    154 <para>The <parameter>-k</parameter> flag is used to make the test suite run
    155 through to completion and not stop at the first failure. The GCC test suite is
    156 very comprehensive and is almost guaranteed to generate a few failures. To get
    157 a summary of the test suite results, run this:</para>
     53<para>To get a summary of the test suite results, run this:</para>
    15854 
    15955<screen><userinput>../gcc-&gcc-version;/contrib/test_summary</userinput></screen>
    16056
    161 <para>(For just the summaries, pipe the output through
    162 <userinput>grep -A7 Summ</userinput>.)</para>
     57<para>For only the summaries, pipe the output through
     58<userinput>grep -A7 Summ</userinput></para>
    16359
    164 <para>You can compare your results to those posted to the gcc-testresults
    165 mailing list for similar configurations to your own. For an example of how
     60<para>Results can be compared to those posted to the gcc-testresults
     61mailing list to see similar configurations to the one being built. For an example of how
    16662current GCC-&gcc-version; should look on i686-pc-linux-gnu, see
    16763<ulink url="http://gcc.gnu.org/ml/gcc-testresults/2004-11/msg00569.html"/>.</para>
    168 
    169 <para>Having a few unexpected failures often cannot be avoided. The GCC
    170 developers are usually aware of these, but haven't yet gotten around to fixing
    171 them. In short, unless your results are vastly different from those at the above
    172 URL, it is safe to continue.</para>
    17364
    17465<para>And finally install the package:</para>
    … …  
    18475</sect2>
    18576
    186 <sect2 role="content"><title/>
    187 <para>The details on this package are found in <xref linkend="contents-gcc"/>.</para>
    188 </sect2>
    189 
    19077</sect1>
Note: See TracChangeset for help on using the changeset viewer.