chapter05/toolchaintechnotes.xml

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