Changes in / [981e0c4:f9e8271]
- Files:
-
- 3 edited
Legend:
- Unmodified
- Added
- Removed
-
chapter04/addinguser.xml
r981e0c4 rf9e8271 63 63 <term><parameter>lfs</parameter></term> 64 64 <listitem> 65 <para>This is the name of the newuser.</para>65 <para>This is the actual name for the created user.</para> 66 66 </listitem> 67 67 </varlistentry> … … 72 72 non-&root; user (as opposed to switching to user &lfs-user; 73 73 when logged in as &root;, which does not require the &lfs-user; user to 74 have a password), you need to set a password for&lfs-user;. Issue the74 have a password), you need to set a password of &lfs-user;. Issue the 75 75 following command as the &root; user to set the password:</para> 76 76 -
chapter04/settingenviron.xml
r981e0c4 rf9e8271 20 20 EOF</userinput></screen> 21 21 22 <para>When logged on as user <systemitem class="username">lfs</systemitem> ,23 or when switched to the &lfs-user; user using an<command>su</command> command24 with the<quote><parameter>-</parameter></quote> option,22 <para>When logged on as user <systemitem class="username">lfs</systemitem> 23 or switched to the &lfs-user; user using a <command>su</command> command 24 with <quote><parameter>-</parameter></quote> option, 25 25 the initial shell is a <emphasis>login</emphasis> shell which reads 26 26 the <filename>/etc/profile</filename> of the host (probably containing some … … 31 31 <envar>TERM</envar>, and <envar>PS1</envar> variables. This ensures that no 32 32 unwanted and potentially hazardous environment variables from the host system 33 leak into the build environment.</para> 33 leak into the build environment. The technique used here achieves the goal of 34 ensuring a clean environment.</para> 34 35 35 36 <para>The new instance of the shell is a <emphasis>non-login</emphasis> … … 114 115 Setting <envar>LC_ALL</envar> to <quote>POSIX</quote> or <quote>C</quote> 115 116 (the two are equivalent) ensures that everything will work as expected in 116 the c ross-compilationenvironment.</para>117 the chroot environment.</para> 117 118 </listitem> 118 119 </varlistentry> … … 122 123 <listitem> 123 124 <para>The <envar>LFS_TGT</envar> variable sets a non-default, but compatible machine 124 description for use when building our cross -compiler and linker and when125 c ross-compiling our temporary toolchain. More information is provided by125 description for use when building our cross compiler and linker and when cross 126 compiling our temporary toolchain. More information is contained in 126 127 <xref linkend="ch-tools-toolchaintechnotes" role=""/>.</para> 127 128 </listitem> … … 146 147 <listitem> 147 148 <para>If <filename class="directory">/bin</filename> is not a symbolic 148 link, it mustbe added to the <envar>PATH</envar> variable.</para>149 link, then it has to be added to the <envar>PATH</envar> variable.</para> 149 150 </listitem> 150 151 </varlistentry> … … 177 178 <term><parameter>export ...</parameter></term> 178 179 <listitem> 179 <para>While the precedingcommands have set some variables, in order180 <para>While the above commands have set some variables, in order 180 181 to make them visible within any sub-shells, we export them.</para> 181 182 </listitem> … … 186 187 <important> 187 188 188 <para>Several commercial distributions add a n undocumented instantiation189 <para>Several commercial distributions add a non-documented instantiation 189 190 of <filename>/etc/bash.bashrc</filename> to the initialization of 190 191 <command>bash</command>. This file has the potential to modify the … … 199 200 <screen role="nodump"><userinput>[ ! -e /etc/bash.bashrc ] || mv -v /etc/bash.bashrc /etc/bash.bashrc.NOUSE</userinput></screen> 200 201 201 <para> Whenthe <systemitem class="username">lfs</systemitem>202 user is no longer needed (at the beginning of <xref203 linkend="chapter-chroot-temporary-tools"/> ), you may safelyrestore202 <para>After use of the <systemitem class="username">lfs</systemitem> 203 user is finished at the beginning of <xref 204 linkend="chapter-chroot-temporary-tools"/>, you can restore 204 205 <filename>/etc/bash.bashrc</filename> (if desired).</para> 205 206 … … 210 211 </important> 211 212 212 <para>Finally, to ensure the environment isfully prepared for building the213 <para>Finally, to have the environment fully prepared for building the 213 214 temporary tools, force the <command>bash</command> shell to read 214 215 the new user profile:</para> -
part3intro/toolchaintechnotes.xml
r981e0c4 rf9e8271 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 -toolchain for some purpose other43 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 the packages involved with cross-compilationuse an148 <para>All packages involved with cross compilation in the book 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 often 152 irrelevant, autoconf lets you omit it.</para> 153 154 <para>An astute reader may wonder 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 155 153 why a <quote>triplet</quote> refers to a four component name. The 156 kernel field and the os field began as a single154 reason is the kernel field and the os field originated from one 157 155 <quote>system</quote> field. Such a three-field form is still valid 158 today for some systems, for example ,159 <literal>x86_64-unknown-freebsd</literal>. But 160 two systems can share the same kernel andstill be too different to161 use the same triplet to describe them. For example,Android running on a156 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 but still be too different to 159 use a same triplet for them. For example, an Android running on a 162 160 mobile phone is completely different from Ubuntu running on an ARM64 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 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 170 167 system is designated <literal>aarch64-unknown-linux-android</literal>, 171 168 and the Ubuntu system is designated 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 169 <literal>aarch64-unknown-linux-gnu</literal>. The word 170 <quote>triplet</quote> remained. A simple way to determine your 175 171 system triplet is to run the <command>config.guess</command> 176 172 script that comes with the source for many packages. Unpack the binutils 177 sources , run the script <userinput>./config.guess</userinput>,and note173 sources and run the script: <userinput>./config.guess</userinput> and note 178 174 the output. For example, for a 32-bit Intel processor the 179 175 output will be <emphasis>i686-pc-linux-gnu</emphasis>. On a 64-bit … … 198 194 </note> 199 195 200 <para>In order to fake a cross -compilation in LFS, the name of the host triplet196 <para>In order to fake a cross compilation in LFS, the name of the host triplet 201 197 is slightly adjusted by changing the "vendor" field in the 202 198 <envar>LFS_TGT</envar> variable so it says "lfs". We also use the 203 <parameter>--with-sysroot</parameter> option when building the cross -linker and204 cross -compiler to tell them where to find the needed host files. This199 <parameter>--with-sysroot</parameter> option when building the cross linker and 200 cross compiler to tell them where to find the needed host files. This 205 201 ensures that none of the other programs built in <xref 206 202 linkend="chapter-temporary-tools"/> can link to libraries on the build … … 242 238 just a compiler, but also defines a standard library. In this book, the 243 239 GNU C library, named glibc, is used (there is an alternative, "musl"). This library must 244 be compiled for the LFS machine; that is, using the cross -compiler cc1.245 But the compiler itself uses an internal library providing complex240 be compiled for the LFS machine; that is, using the cross compiler cc1. 241 But the compiler itself uses an internal library implementing complex 246 242 subroutines for functions not available in the assembler instruction set. This 247 243 internal library is named libgcc, and it must be linked to the glibc 248 library to be fully functional .Furthermore, the standard library for244 library to be fully functional! Furthermore, the standard library for 249 245 C++ (libstdc++) must also be linked with glibc. The solution to this 250 246 chicken and egg problem is first to build a degraded cc1-based libgcc, … … 254 250 functionality of libgcc.</para> 255 251 256 <para>Th e upshot of the preceding252 <para>This is not the end of the story: the upshot of the preceding 257 253 paragraph is that cc1 is unable to build a fully functional libstdc++, but 258 254 this is the only compiler available for building the C/C++ libraries 259 during stage 2 . Of course, the compiler built bystage 2, cc-lfs,255 during stage 2! Of course, the compiler built during stage 2, cc-lfs, 260 256 would be able to build those libraries, but (1) the build system of 261 gcc does not know cc-lfs can run on pc, and (2) using cc-lfson pc257 gcc does not know that it is usable on pc, and (2) using it on pc 262 258 would create a risk of linking to the pc libraries, since cc-lfs is a native 263 259 compiler. So we have to re-build libstdc++ later as a part of 264 260 gcc stage 2.</para> 265 261 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 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 270 267 package on a complete LFS system, the installed content of the package 271 should be the same as the content of the same package wheninstalled in268 should be same as the content of the same package installed in 272 269 &ch-final;. The temporary packages installed in &ch-tmp-cross; or 273 &ch-tmp-chroot; cannot satisfy this requirement,because some of them274 are built without optional dependencies , and autoconf cannot275 perform some feature checks in &ch-tmp-cross; because of cross -compilation,276 c ausing the temporary packages to lack optional features,270 &ch-tmp-chroot; cannot satisfy this expectation because some of them 271 are built without optional dependencies installed, and autoconf cannot 272 perform some feature checks in &ch-tmp-cross; because of cross 273 compilation, causing the temporary packages to lack optional features 277 274 or use suboptimal code routines. Additionally, a minor reason for 278 rebuilding the packages is to run the test suites.</para>275 rebuilding the packages is allowing to run the testsuite.</para> 279 276 280 277 </sect2> … … 282 279 <sect2 id="other-details"> 283 280 284 <title>Other Procedural Details</title>281 <title>Other procedural details</title> 285 282 286 283 <para>The cross-compiler will be installed in a separate <filename … … 304 301 <command>ld</command> by passing it the <parameter>--verbose</parameter> 305 302 flag. For example, <command>$LFS_TGT-ld --verbose | grep SEARCH</command> 306 will illustrate the current search paths and their order. (Note that this307 example can be run as shown only while logged in asuser303 will illustrate the current search paths and their order. Note that this 304 example can be run as shown only while being user 308 305 <systemitem class="username">lfs</systemitem>. If you come back to this 309 page later, replace <command>$LFS_TGT-ld</command> with 310 <command>ld</command> ).</para>306 page later, replace <command>$LFS_TGT-ld</command> with just 307 <command>ld</command>.</para> 311 308 312 309 <para>The next package installed is gcc. An example of what can be … … 321 318 operation of <command>gcc</command> itself, the same search paths are not 322 319 necessarily used. To find out which standard linker <command>gcc</command> 323 will use, run: <command>$LFS_TGT-gcc -print-prog-name=ld</command>. (Again,324 remove the <command>$LFS_TGT-</command> p refixif coming back to this325 later. )</para>320 will use, run: <command>$LFS_TGT-gcc -print-prog-name=ld</command>. Again, 321 remove the <command>$LFS_TGT-</command> part if coming back to this 322 later.</para> 326 323 327 324 <para>Detailed information can be obtained from <command>gcc</command> by … … 329 326 a program. For example, <command>$LFS_TGT-gcc -v 330 327 <replaceable>example.c</replaceable></command> (or without <command> 331 $LFS_TGT-</command> if coming back later ) will show328 $LFS_TGT-</command> if coming back later to this) will show 332 329 detailed information about the preprocessor, compilation, and assembly 333 330 stages, including <command>gcc</command>'s search paths for included 334 331 headers and their order.</para> 335 332 336 <para>Next up:sanitized Linux API headers. These allow the333 <para>Next installed are sanitized Linux API headers. These allow the 337 334 standard C library (glibc) to interface with features that the Linux 338 335 kernel will provide.</para> 339 336 340 <para> Next comes glibc. The most important337 <para>The next package installed is glibc. The most important 341 338 considerations for building glibc are the compiler, binary tools, and 342 339 kernel headers. The compiler is generally not an issue since glibc will 343 340 always use the compiler relating to the <parameter>--host</parameter> 344 parameter passed to its configure script; e.g. ,in our case, the compiler341 parameter passed to its configure script; e.g. in our case, the compiler 345 342 will be <command>$LFS_TGT-gcc</command>. The binary tools and kernel 346 343 headers can be a bit more complicated. Therefore, we take no risks and use … … 354 351 <parameter>-isystem</parameter> flags to control the compiler's include 355 352 search path. These items highlight an important aspect of the glibc 356 package—it is very self-sufficient in terms of its build machinery ,353 package—it is very self-sufficient in terms of its build machinery 357 354 and generally does not rely on toolchain defaults.</para> 358 355 359 356 <para>As mentioned above, the standard C++ library is compiled next, followed in 360 <xref linkend="chapter-temporary-tools"/> by other programs that must361 be cross-compiled to breakcircular dependencies at build time.357 <xref linkend="chapter-temporary-tools"/> by other programs that need 358 to be cross compiled for breaking circular dependencies at build time. 362 359 The install step of all those packages uses the 363 360 <envar>DESTDIR</envar> variable to force installation … … 381 378 core toolchain is self-contained and self-hosted. In 382 379 <xref linkend="chapter-building-system"/>, final versions of all the 383 packages needed for a fully functional system are built, tested ,and380 packages needed for a fully functional system are built, tested and 384 381 installed.</para> 385 382
Note:
See TracChangeset
for help on using the changeset viewer.