- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
part3intro/toolchaintechnotes.xml
r8b539af rc389124 41 41 <para> 42 42 The LFS book is not (and does not contain) a general tutorial to 43 build a cross (or native) toolchain. Don't use the commands in the44 book for a cross 43 build a cross- (or native) toolchain. Don't use the commands in the 44 book for a cross-toolchain for some purpose other 45 45 than building LFS, unless you really understand what you are doing. 46 46 </para> … … 75 75 76 76 <para>As an example, let us imagine the following scenario (sometimes 77 referred to as <quote>Canadian Cross</quote>) : we have a77 referred to as <quote>Canadian Cross</quote>). We have a 78 78 compiler on a slow machine only, let's call it machine A, and the compiler 79 79 ccA. We also have a fast machine (B), but no compiler for (B), and we … … 146 146 147 147 <note> 148 <para>All packages involved with cross compilation in the bookuse an148 <para>All the packages involved with cross-compilation use an 149 149 autoconf-based building system. The autoconf-based building system 150 150 accepts system types in the form cpu-vendor-kernel-os, 151 referred to as the system triplet. Since the vendor field is mostly 152 irrelevant, autoconf allows to omit it. An astute reader may wonder 151 referred to as the system triplet. Since the vendor field is often 152 irrelevant, autoconf lets you omit it.</para> 153 154 <para>An astute reader may wonder 153 155 why a <quote>triplet</quote> refers to a four component name. The 154 reason is the kernel field and the os field originated from one156 kernel field and the os field began as a single 155 157 <quote>system</quote> field. Such a three-field form is still valid 156 today for some systems, for example 157 <literal>x86_64-unknown-freebsd</literal>. But for other systems,158 two systems can share the same kernel butstill be too different to159 use a same triplet for them. For example, anAndroid running on a158 today for some systems, for example, 159 <literal>x86_64-unknown-freebsd</literal>. But 160 two systems can share the same kernel and still be too different to 161 use the same triplet to describe them. For example, Android running on a 160 162 mobile phone is completely different from Ubuntu running on an ARM64 161 server, despite they are running on the same type of CPU (ARM64) and 162 using the same kernel (Linux). 163 Without an emulation layer, you cannot run an 164 executable for the server on the mobile phone or vice versa. So the 165 <quote>system</quote> field is separated into kernel and os fields to 166 designate these systems unambiguously. For our example, the Android 163 server, even though they are both running on the same type of CPU (ARM64) and 164 using the same kernel (Linux).</para> 165 166 <para>Without an emulation layer, you cannot run an 167 executable for a server on a mobile phone or vice versa. So the 168 <quote>system</quote> field has been divided into kernel and os fields, to 169 designate these systems unambiguously. In our example, the Android 167 170 system is designated <literal>aarch64-unknown-linux-android</literal>, 168 171 and the Ubuntu system is designated 169 <literal>aarch64-unknown-linux-gnu</literal>. The word 170 <quote>triplet</quote> remained. A simple way to determine your 172 <literal>aarch64-unknown-linux-gnu</literal>.</para> 173 174 <para>The word <quote>triplet</quote> remains embedded in the lexicon. A simple way to determine your 171 175 system triplet is to run the <command>config.guess</command> 172 176 script that comes with the source for many packages. Unpack the binutils 173 sources and run the script: <userinput>./config.guess</userinput>and note177 sources, run the script <userinput>./config.guess</userinput>, and note 174 178 the output. For example, for a 32-bit Intel processor the 175 179 output will be <emphasis>i686-pc-linux-gnu</emphasis>. On a 64-bit … … 194 198 </note> 195 199 196 <para>In order to fake a cross 200 <para>In order to fake a cross-compilation in LFS, the name of the host triplet 197 201 is slightly adjusted by changing the "vendor" field in the 198 202 <envar>LFS_TGT</envar> variable so it says "lfs". We also use the 199 <parameter>--with-sysroot</parameter> option when building the cross 200 cross 203 <parameter>--with-sysroot</parameter> option when building the cross-linker and 204 cross-compiler to tell them where to find the needed host files. This 201 205 ensures that none of the other programs built in <xref 202 206 linkend="chapter-temporary-tools"/> can link to libraries on the build … … 238 242 just a compiler, but also defines a standard library. In this book, the 239 243 GNU C library, named glibc, is used (there is an alternative, "musl"). This library must 240 be compiled for the LFS machine; that is, using the cross 241 But the compiler itself uses an internal library implementing complex244 be compiled for the LFS machine; that is, using the cross-compiler cc1. 245 But the compiler itself uses an internal library providing complex 242 246 subroutines for functions not available in the assembler instruction set. This 243 247 internal library is named libgcc, and it must be linked to the glibc 244 library to be fully functional !Furthermore, the standard library for248 library to be fully functional. Furthermore, the standard library for 245 249 C++ (libstdc++) must also be linked with glibc. The solution to this 246 250 chicken and egg problem is first to build a degraded cc1-based libgcc, … … 250 254 functionality of libgcc.</para> 251 255 252 <para>Th is is not the end of the story: the upshot of the preceding256 <para>The upshot of the preceding 253 257 paragraph is that cc1 is unable to build a fully functional libstdc++, but 254 258 this is the only compiler available for building the C/C++ libraries 255 during stage 2 ! Of course, the compiler built duringstage 2, cc-lfs,259 during stage 2. Of course, the compiler built by stage 2, cc-lfs, 256 260 would be able to build those libraries, but (1) the build system of 257 gcc does not know that it is usable on pc, and (2) using iton pc261 gcc does not know cc-lfs can run on pc, and (2) using cc-lfs on pc 258 262 would create a risk of linking to the pc libraries, since cc-lfs is a native 259 263 compiler. So we have to re-build libstdc++ later as a part of 260 264 gcc stage 2.</para> 261 265 262 <para>In &ch-final; (or <quote>stage 3</quote>), all packages needed for 263 the LFS system are built. Even if a package is already installed into 264 the LFS system in a previous chapter, we still rebuild the package 265 unless we are completely sure it's unnecessary. The main reason for 266 rebuilding these packages is to settle them down: if we reinstall a LFS 266 <para>In &ch-final; (or <quote>stage 3</quote>), all the packages needed for 267 the LFS system are built. Even if a package has already been installed into 268 the LFS system in a previous chapter, we still rebuild the package. The main reason for 269 rebuilding these packages is to make them stable: if we reinstall a LFS 267 270 package on a complete LFS system, the installed content of the package 268 should be same as the content of the same packageinstalled in271 should be the same as the content of the same package when installed in 269 272 &ch-final;. The temporary packages installed in &ch-tmp-cross; or 270 &ch-tmp-chroot; cannot satisfy this expectationbecause some of them271 are built without optional dependencies installed, and autoconf cannot272 perform some feature checks in &ch-tmp-cross; because of cross 273 c ompilation, causing the temporary packages to lack optional features273 &ch-tmp-chroot; cannot satisfy this requirement, because some of them 274 are built without optional dependencies, and autoconf cannot 275 perform some feature checks in &ch-tmp-cross; because of cross-compilation, 276 causing the temporary packages to lack optional features, 274 277 or use suboptimal code routines. Additionally, a minor reason for 275 rebuilding the packages is allowing to run the testsuite.</para>278 rebuilding the packages is to run the test suites.</para> 276 279 277 280 </sect2> … … 279 282 <sect2 id="other-details"> 280 283 281 <title>Other procedural details</title>284 <title>Other Procedural Details</title> 282 285 283 286 <para>The cross-compiler will be installed in a separate <filename … … 301 304 <command>ld</command> by passing it the <parameter>--verbose</parameter> 302 305 flag. For example, <command>$LFS_TGT-ld --verbose | grep SEARCH</command> 303 will illustrate the current search paths and their order. Note that this304 example can be run as shown only while beinguser306 will illustrate the current search paths and their order. (Note that this 307 example can be run as shown only while logged in as user 305 308 <systemitem class="username">lfs</systemitem>. If you come back to this 306 page later, replace <command>$LFS_TGT-ld</command> with just307 <command>ld</command> .</para>309 page later, replace <command>$LFS_TGT-ld</command> with 310 <command>ld</command>).</para> 308 311 309 312 <para>The next package installed is gcc. An example of what can be … … 318 321 operation of <command>gcc</command> itself, the same search paths are not 319 322 necessarily used. To find out which standard linker <command>gcc</command> 320 will use, run: <command>$LFS_TGT-gcc -print-prog-name=ld</command>. Again,321 remove the <command>$LFS_TGT-</command> p artif coming back to this322 later. </para>323 will use, run: <command>$LFS_TGT-gcc -print-prog-name=ld</command>. (Again, 324 remove the <command>$LFS_TGT-</command> prefix if coming back to this 325 later.)</para> 323 326 324 327 <para>Detailed information can be obtained from <command>gcc</command> by … … 326 329 a program. For example, <command>$LFS_TGT-gcc -v 327 330 <replaceable>example.c</replaceable></command> (or without <command> 328 $LFS_TGT-</command> if coming back later to this) will show331 $LFS_TGT-</command> if coming back later) will show 329 332 detailed information about the preprocessor, compilation, and assembly 330 333 stages, including <command>gcc</command>'s search paths for included 331 334 headers and their order.</para> 332 335 333 <para>Next installed aresanitized Linux API headers. These allow the336 <para>Next up: sanitized Linux API headers. These allow the 334 337 standard C library (glibc) to interface with features that the Linux 335 338 kernel will provide.</para> 336 339 337 <para> The next package installed is glibc. The most important340 <para>Next comes glibc. The most important 338 341 considerations for building glibc are the compiler, binary tools, and 339 342 kernel headers. The compiler is generally not an issue since glibc will 340 343 always use the compiler relating to the <parameter>--host</parameter> 341 parameter passed to its configure script; e.g. in our case, the compiler344 parameter passed to its configure script; e.g., in our case, the compiler 342 345 will be <command>$LFS_TGT-gcc</command>. The binary tools and kernel 343 346 headers can be a bit more complicated. Therefore, we take no risks and use … … 351 354 <parameter>-isystem</parameter> flags to control the compiler's include 352 355 search path. These items highlight an important aspect of the glibc 353 package—it is very self-sufficient in terms of its build machinery 356 package—it is very self-sufficient in terms of its build machinery, 354 357 and generally does not rely on toolchain defaults.</para> 355 358 356 359 <para>As mentioned above, the standard C++ library is compiled next, followed in 357 <xref linkend="chapter-temporary-tools"/> by other programs that need358 to be cross compiled for breakingcircular dependencies at build time.360 <xref linkend="chapter-temporary-tools"/> by other programs that must 361 be cross-compiled to break circular dependencies at build time. 359 362 The install step of all those packages uses the 360 363 <envar>DESTDIR</envar> variable to force installation … … 378 381 core toolchain is self-contained and self-hosted. In 379 382 <xref linkend="chapter-building-system"/>, final versions of all the 380 packages needed for a fully functional system are built, tested and383 packages needed for a fully functional system are built, tested, and 381 384 installed.</para> 382 385
Note:
See TracChangeset
for help on using the changeset viewer.