gcc-pass2.xml 8.1 KB

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