Ignore:
Timestamp:
12/20/2004 05:49:20 PM (19 years ago)
Author:
Manuel Canales Esparcia <manuel@…>
Branches:
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.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, 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
Children:
e0a04e8
Parents:
fba1478
Message:

Removed text in chapter 05 - last round.

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

File:
1 edited

Legend:

Unmodified
Added
Removed

  • chapter05/toolchaintechnotes.xml

    rfba1478 r24244831  
    88<?dbhtml filename="toolchaintechnotes.html"?>
    99
    10 <para>This section attempts to explain some of the rationale and technical
    11 details behind the overall build method. It's not essential that you understand
    12 everything here immediately. Most of it will make sense once you have performed
    13 an actual build. Feel free to refer back here at any time.</para>
    14 
    15 <para>The overall goal of <xref linkend="chapter-temporary-tools"/> is to provide a sane,
    16 temporary environment that we can chroot into, and from which we can produce a
    17 clean, trouble-free build of the target LFS system in
    18 <xref linkend="chapter-building-system"/>. Along the way, we attempt to divorce ourselves
    19 from the host system as much as possible, and in so doing build a
    20 self-contained and self-hosted toolchain. It should be noted that the
    21 build process has been designed to minimize the risks for
    22 new readers and provide maximum educational value at the same time. In other
    23 words, more advanced techniques could be used to build the system.</para>
    24 
    25 <important>
    26 <para>Before continuing, you really should be aware of the name of your working
    27 platform, often also referred to as the <emphasis>target triplet</emphasis>. For
    28 many folks the target triplet will probably be
    29 <emphasis>i686-pc-linux-gnu</emphasis>. A simple way to determine your target
    30 triplet is to run the <command>config.guess</command> script that comes with
    31 the source for many packages. Unpack the Binutils sources and run the script:
    32 <userinput>./config.guess</userinput> and note the output.</para>
    33 
    34 <para>You'll also need to be aware of the name of your platform's
    35 <emphasis>dynamic linker</emphasis>, often also referred to as the
    36 <emphasis>dynamic loader</emphasis>, not to be confused with the standard linker
    37 <command>ld</command> that is part of Binutils. The dynamic linker is provided
    38 by Glibc and has the job of finding and loading the shared libraries needed by a
    39 program, preparing the program to run and then running it. For most folks the
    40 name of the dynamic linker will be <filename>ld-linux.so.2</filename>. On
    41 platforms that are less prevalent, the name might be
    42 <filename>ld.so.1</filename> and newer 64 bit platforms might even have
    43 something completely different. You should be able to determine the name
    44 of your platform's dynamic linker by looking in the
    45 <filename class="directory">/lib</filename> directory on your host system. A
    46 sure-fire way is to inspect a random binary from your host system by running:
    47 <userinput>readelf -l &lt;name of binary&gt; | grep interpreter</userinput>
    48 and noting the output. The authoritative reference covering all platforms is in
    49 the <filename>shlib-versions</filename> file in the root of the Glibc source
    50 tree.</para>
    51 </important>
    52 
    53 <para>Some key technical points of how the <xref linkend="chapter-temporary-tools"/> build
    54 method works:</para>
    55 
    56 <itemizedlist>
    57 <listitem><para>Similar in principle to cross compiling whereby tools installed
    58 into the same prefix work in cooperation and thus utilize a little GNU
    59 <quote>magic</quote>.</para></listitem>
    60 
    61 <listitem><para>Careful manipulation of the standard linker's library search
    62 path to ensure programs are linked only against libraries we
    63 choose.</para></listitem>
    64 
    65 <listitem><para>Careful manipulation of <command>gcc</command>'s
    66 <filename>specs</filename> file to tell the compiler which target dynamic
    67 linker will be used.</para></listitem>
    68 </itemizedlist>
    69 
    70 <para>Binutils is installed first because the <command>./configure</command> runs of both GCC and Glibc perform various
    71 feature tests on the assembler and linker
    72 to determine which software features to enable
    73 or disable. This is more important than one might first realize. An incorrectly
    74 configured GCC or Glibc can result in a subtly broken toolchain where the impact
    75 of such breakage might not show up until near the end of the build of a whole
    76 distribution. Thankfully, a test suite failure will usually alert us before too
    77 much time is wasted.</para>
    78 
    79 <para>Binutils installs its assembler and linker into two locations,
    80 <filename class="directory">/tools/bin</filename> and
    81 <filename class="directory">/tools/$TARGET_TRIPLET/bin</filename>. In reality,
    82 the tools in one location are hard linked to the other. An important facet of
    83 the linker is its library search order. Detailed information can be obtained
    84 from <command>ld</command> by passing it the <parameter>--verbose</parameter>
    85 flag. For example: <command>ld --verbose | grep SEARCH</command> will
    86 show you the current search paths and their order. You can see what files are
    87 actually linked by <command>ld</command> by compiling a dummy program and
    88 passing the <parameter>--verbose</parameter> switch to the linker. For example:
    89 <userinput>gcc dummy.c -Wl,--verbose 2&gt;&amp;1 | grep succeeded</userinput>
    90 will show you all the files successfully opened during the linking.</para>
    91 
    92 <para>The next package installed is GCC and during its run of
    93 <command>./configure</command> you'll see, for example:</para>
    94 
    95 <blockquote><screen><computeroutput>checking what assembler to use... /tools/i686-pc-linux-gnu/bin/as
    96 checking what linker to use... /tools/i686-pc-linux-gnu/bin/ld</computeroutput></screen></blockquote>
    97 
    98 <para>This is important for the reasons mentioned above. It also demonstrates
    99 that GCC's configure script does not search the PATH directories to find which
    100 tools to use. However, during the actual operation of <command>gcc</command>
    101 itself, the same search paths are not necessarily used. You can find out which
    102 standard linker <command>gcc</command> will use by running:
    103 <userinput>gcc -print-prog-name=ld</userinput>.
    104 Detailed information can be obtained from <command>gcc</command> by passing
    105 it the <parameter>-v</parameter> flag while compiling a dummy program. For
    106 example: <userinput>gcc -v dummy.c</userinput> will show you detailed
    107 information about the preprocessor, compilation and assembly stages, including
    108 <command>gcc</command>'s include search paths and their order.</para>
    109  
    110 <para>The next package installed is Glibc. The most important considerations for
    111 building Glibc are the compiler, binary tools and kernel headers. The compiler
    112 is generally no problem as Glibc will always use the <command>gcc</command>
    113 found in a PATH directory. The binary tools and kernel headers can be a little
    114 more troublesome. Therefore we take no risks and use the available configure
    115 switches to enforce the correct selections. After the run of
    116 <command>./configure</command> you can check the contents of the
    117 <filename>config.make</filename> file in the
    118 <filename class="directory">glibc-build</filename> directory for all the
    119 important details. You'll note some interesting items like the use of
    120 <parameter>CC="gcc -B/tools/bin/"</parameter> to control which binary tools are
    121 used, and also the use of the <parameter>-nostdinc</parameter> and
    122 <parameter>-isystem</parameter> flags to control the compiler's include search
    123 path. These items help to highlight an important aspect of the Glibc package:
    124 it is very self-sufficient in terms of its build machinery and generally does
    125 not rely on toolchain defaults.</para>
    126 
    127 <para>After the Glibc installation, we make some adjustments to ensure that
    128 searching and linking take place only within our <filename class="directory">/tools</filename>
    129 prefix. We install an adjusted <command>ld</command>, which has a hard-wired
    130 search path limited to <filename class="directory">/tools/lib</filename>. Then
    131 we amend <command>gcc</command>'s specs file to point to our new dynamic
    132 linker in <filename class="directory">/tools/lib</filename>. This last step is
    133 <emphasis>vital</emphasis> to the whole process. As mentioned above, a
    134 hard-wired path to a dynamic linker is embedded into every ELF shared
    135 executable. You can inspect this by running:
    136 <userinput>readelf -l &lt;name of binary&gt; | grep interpreter</userinput>.
    137 By amending <command>gcc</command>'s specs file, we are ensuring that every
    138 program compiled from here through the end of this chapter will use our new
    139 dynamic linker in <filename class="directory">/tools/lib</filename>.</para>
    140 
    141 <para>The need to use the new dynamic linker is also the reason why we apply the
    142 Specs patch for the second pass of GCC. Failure to do so will result in the GCC
    143 programs themselves having the name of the dynamic linker from the host system's
    144 <filename class="directory">/lib</filename> directory embedded into them, which
    145 would defeat our goal of getting away from the host.</para>
    146 
    147 <para>During the second pass of Binutils, we are able to utilize the
    148 <parameter>--with-lib-path</parameter> configure switch to control
    149 <command>ld</command>'s library search path. From this point onwards, the
    150 core toolchain is self-contained and self-hosted. The remainder of the
    151 <xref linkend="chapter-temporary-tools"/> packages all build against the new Glibc in
    152 <filename class="directory">/tools</filename> and all is well.</para>
    153 
    154 <para>Upon entering the chroot environment in <xref linkend="chapter-building-system"/>, the
    155 first major package we install is Glibc, due to its self-sufficient nature that
    156 we mentioned above. Once this Glibc is installed into
    157 <filename class="directory">/usr</filename>, we perform a quick changeover of
    158 the toolchain defaults, then proceed for real in building the rest of the
    159 target LFS system.</para>
    160 
    161 <sect2>
    162 <title>Notes on static linking</title>
    163 
    164 <para>Most programs have to perform, beside their specific task, many rather
    165 common and sometimes trivial operations. These include allocating memory,
    166 searching directories, reading and writing files, string handling, pattern
    167 matching, arithmetic and many other tasks. Instead of obliging each program to
    168 reinvent the wheel, the GNU system provides all these basic functions in
    169 ready-made libraries. The major library on any Linux system is
    170 <emphasis>Glibc</emphasis>.</para>
    171 
    172 <para>There are two primary ways of linking the functions from a library to a
    173 program that uses them: statically or dynamically. When a program is linked
    174 statically, the code of the used functions is included in the executable,
    175 resulting in a rather bulky program. When a program is dynamically linked, what
    176 is included is a reference to the dynamic linker, the name of the library, and
    177 the name of the function, resulting in a much smaller executable. (A third way
    178 is to use the programming interface of the dynamic linker. See the
    179 <emphasis>dlopen</emphasis> man page for more information.)</para>
    180 
    181 <para>Dynamic linking is the default on Linux and has three major advantages
    182 over static linking. First, you need only one copy of the executable library
    183 code on your hard disk, instead of having many copies of the same code included
    184 into a whole bunch of programs -- thus saving disk space. Second, when several
    185 programs use the same library function at the same time, only one copy of the
    186 function's code is required in core -- thus saving memory space. Third, when a
    187 library function gets a bug fixed or is otherwise improved, you only need to
    188 recompile this one library, instead of having to recompile all the programs that
    189 make use of the improved function.</para>
    190 
    191 <para>If dynamic linking has several advantages, why then do we statically link
    192 the first two packages in this chapter? The reasons are threefold: historical,
    193 educational, and technical. Historical, because earlier versions of LFS
    194 statically linked every program in this chapter. Educational, because knowing
    195 the difference is useful. Technical, because we gain an element of independence
    196 from the host in doing so, meaning that those programs can be used
    197 independently of the host system. However, it's worth noting that an overall
    198 successful LFS build can still be achieved when the first two packages are
    199 built dynamically.</para>
    200 
    201 </sect2>
     10<para>See testing</para>
    20211
    20312</sect1>
Note: See TracChangeset for help on using the changeset viewer.