source: chapter05/gcc-pass2-inst.xml@ 3985670

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.0 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 v5_0 v5_1 v5_1_1 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
Last change on this file since 3985670 was 3985670, checked in by Greg Schafer <greg@…>, 21 years ago

Appendix A and Entities cleanup.

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

  • Property mode set to 100644
File size: 7.6 KB
Line 
1<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
2
3<sect2>
4<title>Re-installation of GCC</title>
5
6<para>The tools required to test GCC and Binutils are installed now (Tcl, Expect
7and DejaGnu). We can continue on rebuilding GCC and Binutils, link them against
8the new Glibc, and test them properly. One thing to note, however, is that these
9test suites are highly dependent on properly functioning pseudo terminals (PTYs)
10which are provided by your host distribution. These days, PTYs are most commonly
11implemented via the <emphasis>devpts</emphasis> file system. You can quickly
12check if your host system is set up correctly in this regard by performing a
13simple test:</para>
14
15<para><screen><userinput>expect -c "spawn ls"</userinput></screen></para>
16
17<para>If you receive the message:</para>
18
19<blockquote><screen>The system has no more ptys. Ask your system administrator to create more.</screen></blockquote>
20
21<para>Your host distribution is not set up for proper PTY operation. In this
22case there is no point in running the test suites for GCC and Binutils until you
23are able to resolve the issue. You can consult the LFS Wiki at
24<ulink url="http://wiki.linuxfromscratch.org"/> for more information on how to
25get PTYs working.</para>
26
27<note><para>It's worth pointing out that the GCC test suite we run in this
28section is considered not as important as the one we run in Chapter 6.</para></note>
29
30<para>Unpack all three GCC tarballs (-core, -g++, and -testsuite) in one and the
31same working directory. They will all unfold into a single
32<filename>gcc-&gcc-version;/</filename> subdirectory.</para>
33
34<para>First correct one problem and make an essential adjustment:</para>
35
36<para><screen><userinput>patch -Np1 -i ../gcc-&gcc-nofixincludes-patch-version;.patch
37patch -Np1 -i ../gcc-&gcc-specs-patch-version;.patch</userinput></screen></para>
38
39<para>The first patch disables the GCC "fixincludes" script. We mentioned this
40briefly earlier, but a slightly more in-depth explanation of the fixincludes
41process is warranted here. Under normal circumstances, the GCC fixincludes
42script scans your system for header files that need to be fixed. It might find
43that some Glibc header files on your host system need to be fixed, fix them and
44put them in the GCC private include directory. Then, later on in Chapter 6,
45after we've installed the newer Glibc, this private include directory would be
46searched before the system include directory, resulting in GCC finding the
47fixed headers from the host system, which would most likely not match the Glibc
48version actually used for the LFS system.</para>
49
50<para>The last patch changes GCC's default location of the dynamic linker
51(typically <filename>ld-linux.so.2</filename>). It also removes
52<filename class="directory">/usr/include</filename> from GCC's include search
53path. Patching now rather than adjusting the specs file after installation
54ensures that our new dynamic linker gets used during the actual build of GCC.
55That is, all the final (and temporary) binaries created during the build will
56link against the new Glibc.</para>
57
58<important><para>These patches are <emphasis>critical</emphasis> in ensuring a
59successful overall build. Do not forget to apply them.</para></important>
60
61<para>Create a separate build directory again:</para>
62
63<para><screen><userinput>mkdir ../gcc-build
64cd ../gcc-build</userinput></screen></para>
65
66<para>Before starting to build GCC, remember to unset any environment
67variables that override the default optimization flags.</para>
68
69<para>Now prepare GCC to be compiled:</para>
70
71<para><screen><userinput>../gcc-&gcc-version;/configure --prefix=/tools \
72&nbsp;&nbsp;&nbsp;&nbsp;--with-local-prefix=/tools \
73&nbsp;&nbsp;&nbsp;&nbsp;--enable-clocale=gnu --enable-shared \
74&nbsp;&nbsp;&nbsp;&nbsp;--enable-threads=posix --enable-__cxa_atexit \
75&nbsp;&nbsp;&nbsp;&nbsp;--enable-languages=c,c++</userinput></screen></para>
76
77<para>The meaning of the new configure options:</para>
78
79<itemizedlist>
80<listitem><para><userinput>--enable-threads=posix</userinput>: This enables
81C++ exception handling for multi-threaded code.</para></listitem>
82
83<listitem><para><userinput>--enable-__cxa_atexit</userinput>: This option
84allows use of __cxa_atexit, rather than atexit, to register C++ destructors for
85local statics and global objects and is essential for fully standards-compliant
86handling of destructors. It also affects the C++ ABI and therefore results in
87C++ shared libraries and C++ programs that are interoperable with other Linux
88distributions.</para></listitem>
89
90<listitem><para><userinput>--enable-clocale=gnu</userinput>: This option ensures
91the correct locale model is selected for the C++ libraries under all
92circumstances. If the configure script finds the <emphasis>de_DE</emphasis>
93locale installed, it will select the correct model of <emphasis>gnu</emphasis>.
94However, people who don't install the <emphasis>de_DE</emphasis> locale, run the
95risk of building ABI incompatible C++ libraries due to the wrong locale model of
96<emphasis>generic</emphasis> being selected.</para></listitem>
97
98<listitem><para><userinput>--enable-languages=c,c++</userinput>: This option is
99needed to ensure that both C and C++ compilers are built.</para></listitem>
100</itemizedlist>
101
102<para>Compile the package:</para>
103
104<para><screen><userinput>make</userinput></screen></para>
105
106<para>There is no need to use the <userinput>bootstrap</userinput> target now,
107as the compiler we're using to compile this GCC was built from the exact same
108version of the GCC sources we used earlier.</para>
109
110<note><para>At this point it is strongly recommended to repeat the sanity check
111we performed earlier in the chapter. Refer back to the "Locking in" Glibc section
112and repeat the check. If the results are wrong then most likely, you forgot to
113apply the abovementioned GCC Specs patch.</para></note>
114
115<para>Test the results:</para>
116
117<para><screen><userinput>make -k check</userinput></screen></para>
118
119<para>The <userinput>-k</userinput> flag is used to make the test suite run
120through to completion and not stop at the first failure. The GCC test suite is
121very comprehensive and is almost guaranteed to generate a few failures. To get
122a summary of the test suite results, run this:</para>
123
124<para><screen><userinput>../gcc-&gcc-version;/contrib/test_summary | less</userinput></screen></para>
125
126<para>You can compare your results to those posted to the gcc-testresults
127mailing list for similar configurations to your own. For an example of how
128current GCC-3.3.1 should look on i686-pc-linux-gnu, see
129<ulink url="http://gcc.gnu.org/ml/gcc-testresults/2003-08/msg01612.html"/>.</para>
130
131<para>Note that the results contain:</para>
132
133<screen>* 1 XPASS (unexpected pass) for g++
134* 1 FAIL for g++
135* 2 FAIL for gcc
136* 26 XPASS's for libstdc++</screen>
137
138<para>The unexpected pass for g++ is due to the use of
139<userinput>--enable-__cxa_atexit</userinput>. Apparently not all platforms
140supported by GCC have support for "__cxa_atexit" in their C libraries, so this
141test is not always expected to pass.</para>
142
143<para>The 26 unexpected passes for libstdc++ are due to the use of
144<userinput>--enable-clocale=gnu</userinput>, which is the correct choice on
145Glibc-based systems of versions 2.2.5 and above. The underlying locale support
146in the GNU C library is superior to that of the otherwise selected "generic"
147model (which may be applicable if for instance you were using Newlibc, Sun-libc
148or whatever libc). The libstdc++ test suite is apparently expecting the
149"generic" model, hence those tests are not always expected to pass.</para>
150
151<para>And finally install the package:</para>
152
153<para><screen><userinput>make install</userinput></screen></para>
154
155</sect2>
156
Note: See TracBrowser for help on using the repository browser.