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