source: chapter05/gcc-pass2.xml@ bc827b39

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_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 bc827b39 was bc827b39, checked in by Greg Schafer <greg@…>, 21 years ago

Upgraded to GCC-3.3.2.

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

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