Changeset 6e41459 for chapter05/gcc-pass2.xml
- Timestamp:
- 08/08/2004 02:10:39 AM (20 years ago)
- Branches:
- 6.0
- Children:
- ef13657
- Parents:
- 78349b7
- File:
-
- 1 edited
-
chapter05/gcc-pass2.xml (modified) (7 diffs)
Legend:
- Unmodified
- Added
- Removed
-
chapter05/gcc-pass2.xml
r78349b7 r6e41459 20 20 </segmentedlist> 21 21 22 <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="../chapter06/gcc.xml" xpointer="xpointer(/sect1/sect2[1]/segmentedlist[2])"/> 23 22 24 </sect2> 23 25 … … 25 27 <title>Re-installation of GCC</title> 26 28 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> 29 <para>The tools required to test GCC and Binutils -- Tcl, Expect and 30 DejaGNU -- are installed now. GCC and Binutils can now be rebuilt, 31 linking them against the new Glibc and testing them properly (if 32 running the test suites in this chapter). Please note that these test 33 suites are highly dependent on properly functioning pseudo terminals 34 (PTYs) which are provided by the host. PTYs are most commonly 35 implemented via the <systemitem class="filesystem">devpts</systemitem> 36 file system. Check to see if the host system is set up correctly in 37 this regard by performing a quick test:</para> 35 38 36 39 <screen><userinput>expect -c "spawn ls"</userinput></screen> … … 40 43 <blockquote><screen><computeroutput>The system has no more ptys. Ask your system administrator to create more.</computeroutput></screen></blockquote> 41 44 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> 45 <para>If the above message is received, the host does not have its 46 PTYs set up properly. In this case, there is no point in running the 47 test suites for GCC and Binutils until this issue is resolved. Please 48 consult the LFS Wiki at <ulink url="&wiki-root;"/> for more 49 information on how to get PTYs working.</para> 50 51 <para>Because the C and the C++ compilers will be built, unpack both 52 the core and the g++ tarballs (as well as testsuite, if you want to 53 run the tests). By unpacking them in the working directory, they will 54 all unfold into a single <filename 55 class="directory">gcc-&gcc-version;/</filename> subdirectory.</para> 56 57 <para>First correct a known problem and make an essential adjustment:</para> 54 58 55 59 <screen><userinput>patch -Np1 -i ../gcc-&gcc-version;-no_fixincludes-1.patch 56 60 patch -Np1 -i ../gcc-&gcc-version;-specs-1.patch</userinput></screen> 57 61 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> 62 <para>The first patch disables the GCC <command>fixincludes</command> 63 script. This was briefly mentioned earlier, but a more in-depth 64 explanation of the fixincludes process is warranted here. Under normal 65 circumstances, the GCC <command>fixincludes</command> script scans the 66 system for header files that need to be fixed. It might find that some 67 Glibc header files on the host system need to be fixed, and will fix 68 them and put them in the GCC private include directory. In <xref 69 linkend="chapter-building-system"/>, after the newer Glibc had been 70 installed, this private include directory will be searched before the 71 system include directory. This may result in GCC finding the fixed 72 headers from the host system, which most likely will not match the 73 Glibc version used for the LFS system.</para> 74 75 <para>The second patch changes GCC's default location of the dynamic 76 linker (typically <filename>ld-linux.so.2</filename>). It also removes 77 <filename class="directory">/usr/include</filename> from GCC's include 78 search path. Patching now rather than adjusting the specs file after 79 installation ensures that the new dynamic linker is used during the 80 actual build of GCC. That is, all of the final (and temporary) 81 binaries created during the build will link against the new 82 Glibc.</para> 83 84 <important><para>The above patches are critical in ensuring a 85 successful overall build. Do not forget to apply 86 them.</para></important> 80 87 81 88 <para>Create a separate build directory again:</para> … … 100 107 <varlistentry> 101 108 <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 c ircumstances. 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> locale107 would run the risk of building ABI incompatible C++ libraries due to the wrong 108 <emphasis>generic</emphasis> locale model beingselected.</para></listitem>109 <listitem><para>This option ensures the correct locale model is 110 selected for the C++ libraries under all circumstances. If the 111 configure script finds the <emphasis>de_DE</emphasis> locale installed, it will select the 112 correct gnu locale model. However, if the <emphasis>de_DE</emphasis> locale is not 113 installed, there is the risk of building Application Binary Interface 114 (ABI)-incompatible C++ libraries because the incorrect generic locale 115 model may be selected.</para></listitem> 109 116 </varlistentry> 110 117 111 118 <varlistentry> 112 119 <term><parameter>--enable-threads=posix</parameter></term> 113 <listitem><para>This enables 114 C++ exception handling for multi-threadedcode.</para></listitem>120 <listitem><para>This enables C++ exception handling for multi-threaded 121 code.</para></listitem> 115 122 </varlistentry> 116 123 117 124 <varlistentry> 118 125 <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 126 <listitem><para>This option allows use of 127 <emphasis>__cxa_atexit</emphasis>, rather than 128 <emphasis>atexit</emphasis>, to register C++ destructors for local 129 statics and global objects. This option is essential for fully 130 standards-compliant handling of destructors. It also affects the C++ 131 ABI and therefore results in C++ shared libraries and C++ programs 132 that are interoperable with other Linux 124 133 distributions.</para></listitem> 125 134 </varlistentry> … … 133 142 <varlistentry> 134 143 <term><parameter>--disable-libstdcxx-pch</parameter></term> 135 <listitem><para>Do n't build the136 PCH (pre-compiled header) for libstdc++. It takes up a ton of space, and we 137 have no use forit.</para></listitem>144 <listitem><para>Do not build the pre-compiled header (PCH) for 145 libstdc++. It takes up a lot of space, and we have no use for 146 it.</para></listitem> 138 147 </varlistentry> 139 148 </variablelist> … … 143 152 <screen><userinput>make</userinput></screen> 144 153 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> 154 <para>There is no need to use the <parameter>bootstrap</parameter> 155 target now because the compiler being used to compile this GCC was 156 built from the exact same version of the GCC sources used 157 earlier.</para> 158 159 <para>Compilation is now complete. As previously mentioned, running 160 the test suites for the temporary tools compiled in this chapter is 161 not mandatory. To run the GCC test suite anyway, use the following 162 command:</para> 151 163 152 164 <screen><userinput>make -k check</userinput></screen> 153 165 154 166 <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 is156 very comprehensive and is almost guaranteed to generate a few failures. To get 157 a summary of the test suite results, run this:</para>167 through to completion and not stop at the first failure. The GCC test 168 suite is very comprehensive and is almost guaranteed to generate a few 169 failures. To receive a summary of the test suite results, run:</para> 158 170 159 171 <screen><userinput>../gcc-&gcc-version;/contrib/test_summary</userinput></screen> 160 172 161 <para>(For just the summaries, pipe the output through 162 <userinput>grep -A7 Summ</userinput>.)</para> 163 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 166 current GCC-&gcc-version; should look on i686-pc-linux-gnu, see 167 <ulink url="http://gcc.gnu.org/ml/gcc-testresults/2004-07/msg00179.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> 173 174 <para>And finally install the package:</para> 173 <para>For only the summaries, pipe the output through 174 <userinput>grep -A7 Summ</userinput>.</para> 175 176 <para>Results can be compared to those posted to the gcc-testresults 177 mailing list to see similar configurations to the one being built. For 178 an example of how current GCC-&gcc-version; should look on 179 i686-pc-linux-gnu, see <ulink 180 url="http://gcc.gnu.org/ml/gcc-testresults/2004-07/msg00179.html"/>.</para> 181 182 <para>Having a few unexpected failures often cannot be avoided. The 183 GCC developers are usually aware of these issues, but have not 184 resolved them yet. Unless the test results are vastly different from 185 those at the above URL, it is safe to continue.</para> 186 187 <para>Install the package:</para> 175 188 176 189 <screen><userinput>make install</userinput></screen> 177 190 178 <note><para>At this point it is strongly recommended to repeat the sanity check179 we performed earlier in this chapter. Refer back to 180 <xref linkend="ch-tools-adjusting"/> and repeat the little test compilation.If181 the result is wrong, the n most likely you forgot to apply the above mentioned182 GCC Specs patch.</para></note>191 <note><para>At this point it is strongly recommended to repeat the 192 sanity check we performed earlier in this chapter. Refer back to <xref 193 linkend="ch-tools-adjusting"/> and repeat the test compilation. If 194 the result is wrong, the most likely reason is that the GCC Specs 195 patch was not properly applied.</para></note> 183 196 184 197 </sect2> … … 189 202 190 203 </sect1> 204
Note:
See TracChangeset
for help on using the changeset viewer.
