toolchaintechnotes.xml 9.2 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166
  1. <?xml version="1.0" encoding="ISO-8859-1"?>
  2. <!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
  3. "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
  4. <!ENTITY % general-entities SYSTEM "../general.ent">
  5. %general-entities;
  6. ]>
  7. <sect1 id="ch-tools-toolchaintechnotes">
  8. <?dbhtml filename="toolchaintechnotes.html"?>
  9. <title>Toolchain Technical Notes</title>
  10. <para>This section explains some of the rationale and technical details
  11. behind the overall build method. It is not essential to immediately
  12. understand everything in this section. Most of this information will be
  13. clearer after performing an actual build. This section can be referred
  14. to at any time during the process.</para>
  15. <para>The overall goal of <xref linkend="chapter-temporary-tools"/> is to
  16. produce a temporary area that contains a known-good set of tools that can be
  17. isolated from the host system. By using <command>chroot</command>, the
  18. commands in the remaining chapters will be contained within that environment,
  19. ensuring a clean, trouble-free build of the target LFS system. The build
  20. process has been designed to minimize the risks for new readers and to provide
  21. the most educational value at the same time.</para>
  22. <note>
  23. <para>Before continuing, be aware of the name of the working platform,
  24. often referred to as the target triplet. A simple way to determine the
  25. name of the target triplet is to run the <command>config.guess</command>
  26. script that comes with the source for many packages. Unpack the Binutils
  27. sources and run the script: <userinput>./config.guess</userinput> and note
  28. the output. For example, for a 32-bit Intel processor the
  29. output will be <emphasis>i686-pc-linux-gnu</emphasis>. On a 64-bit
  30. system it will be <emphasis>x86_64-pc-linux-gnu</emphasis>.</para>
  31. <para>Also be aware of the name of the platform's dynamic linker, often
  32. referred to as the dynamic loader (not to be confused with the standard
  33. linker <command>ld</command> that is part of Binutils). The dynamic linker
  34. provided by Glibc finds and loads the shared libraries needed by a program,
  35. prepares the program to run, and then runs it. The name of the dynamic
  36. linker for a 32-bit Intel machine will be <filename
  37. class="libraryfile">ld-linux.so.2</filename> (<filename
  38. class="libraryfile">ld-linux-x86-64.so.2</filename> for 64-bit systems). A
  39. sure-fire way to determine the name of the dynamic linker is to inspect a
  40. random binary from the host system by running: <userinput>readelf -l
  41. &lt;name of binary&gt; | grep interpreter</userinput> and noting the
  42. output. The authoritative reference covering all platforms is in the
  43. <filename>shlib-versions</filename> file in the root of the Glibc source
  44. tree.</para>
  45. </note>
  46. <para>Some key technical points of how the <xref
  47. linkend="chapter-temporary-tools"/> build method works:</para>
  48. <itemizedlist>
  49. <listitem>
  50. <para>Slightly adjusting the name of the working platform, by changing the
  51. &quot;vendor&quot; field target triplet by way of the
  52. <envar>LFS_TGT</envar> variable, ensures that the first build of Binutils
  53. and GCC produces a compatible cross-linker and cross-compiler. Instead of
  54. producing binaries for another architecture, the cross-linker and
  55. cross-compiler will produce binaries compatible with the current
  56. hardware.</para>
  57. </listitem>
  58. <listitem>
  59. <para> The temporary libraries are cross-compiled. Because a
  60. cross-compiler by its nature cannot rely on anything from its host
  61. system, this method removes potential contamination of the target
  62. system by lessening the chance of headers or libraries from the host
  63. being incorporated into the new tools. Cross-compilation also allows for
  64. the possibility of building both 32-bit and 64-bit libraries on 64-bit
  65. capable hardware.</para>
  66. </listitem>
  67. <listitem>
  68. <para>Careful manipulation of the GCC source tells the compiler which target
  69. dynamic linker will be used.</para>
  70. </listitem>
  71. </itemizedlist>
  72. <para>Binutils is installed first because the <command>configure</command>
  73. runs of both GCC and Glibc perform various feature tests on the assembler
  74. and linker to determine which software features to enable or disable. This
  75. is more important than one might first realize. An incorrectly configured
  76. GCC or Glibc can result in a subtly broken toolchain, where the impact of
  77. such breakage might not show up until near the end of the build of an
  78. entire distribution. A test suite failure will usually highlight this error
  79. before too much additional work is performed.</para>
  80. <para>Binutils installs its assembler and linker in two locations,
  81. <filename class="directory">/tools/bin</filename> and <filename
  82. class="directory">/tools/$LFS_TGT/bin</filename>. The tools in one
  83. location are hard linked to the other. An important facet of the linker is
  84. its library search order. Detailed information can be obtained from
  85. <command>ld</command> by passing it the <parameter>--verbose</parameter>
  86. flag. For example, an <userinput>ld --verbose | grep SEARCH</userinput>
  87. will illustrate the current search paths and their order. It shows which
  88. files are linked by <command>ld</command> by compiling a dummy program and
  89. passing the <parameter>--verbose</parameter> switch to the linker. For example,
  90. <userinput>gcc dummy.c -Wl,--verbose 2&gt;&amp;1 | grep succeeded</userinput>
  91. will show all the files successfully opened during the linking.</para>
  92. <para>The next package installed is GCC. An example of what can be
  93. seen during its run of <command>configure</command> is:</para>
  94. <screen><computeroutput>checking what assembler to use... /tools/i686-lfs-linux-gnu/bin/as
  95. checking what linker to use... /tools/i686-lfs-linux-gnu/bin/ld</computeroutput></screen>
  96. <para>This is important for the reasons mentioned above. It also demonstrates
  97. that GCC's configure script does not search the PATH directories to find which
  98. tools to use. However, during the actual operation of <command>gcc</command>
  99. itself, the same search paths are not necessarily used. To find out which
  100. standard linker <command>gcc</command> will use, run:
  101. <userinput>gcc -print-prog-name=ld</userinput>.</para>
  102. <para>Detailed information can be obtained from <command>gcc</command> by
  103. passing it the <parameter>-v</parameter> command line option while compiling
  104. a dummy program. For example, <userinput>gcc -v dummy.c</userinput> will show
  105. detailed information about the preprocessor, compilation, and assembly stages,
  106. including <command>gcc</command>'s included search paths and their order.</para>
  107. <para>Next installed are sanitized Linux API headers. These allow the standard
  108. C library (Glibc) to interface with features that the Linux kernel will
  109. provide.</para>
  110. <para>The next package installed is Glibc. The most important considerations
  111. for building Glibc are the compiler, binary tools, and kernel headers. The
  112. compiler is generally not an issue since Glibc will always use the compiler
  113. relating to the <parameter>--host</parameter> parameter passed to its
  114. configure script, e.g. in our case,
  115. <command>i686-lfs-linux-gnu-gcc</command>. The binary tools and kernel
  116. headers can be a bit more complicated. Therefore, take no risks and use the
  117. available configure switches to enforce the correct selections. After the run
  118. of <command>configure</command>, check the contents of the
  119. <filename>config.make</filename> file in the <filename
  120. class="directory">glibc-build</filename> directory for all important details.
  121. Note the use of <parameter>CC="i686-lfs-gnu-gcc"</parameter> to control which
  122. binary tools are used and the use of the <parameter>-nostdinc</parameter> and
  123. <parameter>-isystem</parameter> flags to control the compiler's include
  124. search path. These items highlight an important aspect of the Glibc
  125. package&mdash;it is very self-sufficient in terms of its build machinery and
  126. generally does not rely on toolchain defaults.</para>
  127. <para>During the second pass of Binutils, we are able to utilize the
  128. <parameter>--with-lib-path</parameter> configure switch to control
  129. <command>ld</command>'s library search path.</para>
  130. <para>For the second pass of GCC, its sources also need to be modified to
  131. tell GCC to use the new dynamic linker. Failure to do so will result in the
  132. GCC programs themselves having the name of the dynamic linker from the host
  133. system's <filename class="directory">/lib</filename> directory embedded into
  134. them, which would defeat the goal of getting away from the host. From this
  135. point onwards, the core toolchain is self-contained and self-hosted. The
  136. remainder of the <xref linkend="chapter-temporary-tools"/> packages all build
  137. against the new Glibc in <filename
  138. class="directory">/tools</filename>.</para>
  139. <para>Upon entering the chroot environment in <xref
  140. linkend="chapter-building-system"/>, the first major package to be
  141. installed is Glibc, due to its self-sufficient nature mentioned above.
  142. Once this Glibc is installed into <filename
  143. class="directory">/usr</filename>, we will perform a quick changeover of the
  144. toolchain defaults, and then proceed in building the rest of the target
  145. LFS system.</para>
  146. </sect1>