Changeset f4993cf for chapter05/chapter05.xml
- Timestamp:
- 01/12/2004 11:24:06 PM (20 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.0, 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, v5_1, v5_1_1, 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:
- 9702d12
- Parents:
- 5888299
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
chapter05/chapter05.xml
r5888299 rf4993cf 78 78 <para>Before continuing, you really should be aware of the name of your working 79 79 platform, often also referred to as the <emphasis>target triplet</emphasis>. For 80 many folks the target triplet will be, for example:80 many folks the target triplet will probably be 81 81 <emphasis>i686-pc-linux-gnu</emphasis>. A simple way to determine your target 82 82 triplet is to run the <filename>config.guess</filename> script that comes with … … 89 89 <emphasis>ld</emphasis> that is part of Binutils. The dynamic linker is provided 90 90 by Glibc and has the job of finding and loading the shared libraries needed by a 91 program, preparing the program to run and then running it. For most folks ,the91 program, preparing the program to run and then running it. For most folks the 92 92 name of the dynamic linker will be <emphasis>ld-linux.so.2</emphasis>. On 93 93 platforms that are less prevalent, the name might be … … 267 267 in a separate directory, we can later easily throw them away.</para> 268 268 269 <para>If later you wish to search through the binaries of your system to see 270 what files they make use of or link against, then to make this searching easier 271 you may want to choose a unique name. Instead of the simple "tools" you could 272 use something like "tools-for-lfs". However, you'll need to be careful to 273 adjust all references to "tools" throughout the book including those in any 274 patches, the most notable being the GCC Specs Patch.</para> 269 <para>Later on you might wish to search through the binaries of your system to 270 see what files they make use of or link against. To make this searching easier 271 you may want to choose a unique name for the directory in which the temporary 272 tools are stored. Instead of the simple "tools" you could use something like 273 "tools-for-lfs". However, you'll need to be careful to adjust all references to 274 "tools" throughout the book -- including those in any patches, notably the 275 GCC Specs Patch.</para> 275 276 276 277 <para>Create the required directory by running the following:</para> … … 284 285 <screen><userinput>ln -s $LFS/tools /</userinput></screen> 285 286 286 <para>This symlink enables us to compile our toolchain so that it always 287 <note><para>The above command is correct. The <userinput>ln</userinput> command 288 has a few syntactic variations, so be sure to check the info page before 289 reporting what you may think is an error.</para></note> 290 291 <para>The created symlink enables us to compile our toolchain so that it always 287 292 refers to <filename>/tools</filename>, meaning that the compiler, assembler 288 293 and linker will work both in this chapter (when we are still using some tools 289 294 from the host) <emphasis>and</emphasis> in the next (when we are chrooted to 290 295 the LFS partition).</para> 291 292 <note><para>Study the above command closely. It can be confusing at first293 glance. The <userinput>ln</userinput> command has several syntax variations,294 so be sure to check the ln man page before reporting what you may think is an295 error.</para></note>296 296 297 297 </sect1> … … 331 331 332 332 <para>The "<userinput>-</userinput>" instructs <userinput>su</userinput> to 333 start a new, cleanshell.</para>333 start a <emphasis>login</emphasis> shell.</para> 334 334 335 335 </sect1> … … 341 341 342 342 <para>We're going to set up a good working environment by creating two new 343 startup files for the Bash shell. While logged in as user344 <emphasis>lfs</emphasis>, issue the following commandsto create a new343 startup files for the <userinput>bash</userinput> shell. While logged in as 344 user <emphasis>lfs</emphasis>, issue the following command to create a new 345 345 <filename>.bash_profile</filename>:</para> 346 346 … … 349 349 <userinput>EOF</userinput></screen> 350 350 351 <para>The 352 <userinput>exec env -i HOME=$HOME TERM=$TERM PS1='\u:\w\$ ' /bin/bash</userinput> 353 command creates a new instance of Bash with a completely empty environment, 354 except for the HOME, TERM and PS1 variables. This is needed to ensure that no 355 unwanted and potentially hazardous environment variables from the host system 356 leak into our build environment. The technique used here is a little 357 non-standard but it achieves the goal of enforcing a clean environment. By way 358 of explanation, the initial shell is a <emphasis>login</emphasis> shell which 359 reads the <filename>.bash_profile</filename>. The new shell instance is a 360 <emphasis>non-login</emphasis> shell which reads the 361 <filename>.bashrc</filename> (created next).</para> 362 363 <para>Now create a new <filename>.bashrc</filename>:</para> 351 <para>Normally, when you log on as user <emphasis>lfs</emphasis>, 352 the initial shell is a <emphasis>login</emphasis> shell which reads the 353 <filename>/etc/profile</filename> of your host (probably containing some 354 settings of environment variables) and then <filename>.bash_profile</filename>. 355 The <userinput>exec env -i ... /bin/bash</userinput> command in the latter file 356 replaces the running shell with a new one with a completely empty environment, 357 except for the HOME, TERM and PS1 variables. This ensures that no unwanted and 358 potentially hazardous environment variables from the host system leak into our 359 build environment. The technique used here is a little strange, but it achieves 360 the goal of enforcing a clean environment.</para> 361 362 <para>The new instance of the shell is a <emphasis>non-login</emphasis> shell, 363 which doesn't read the <filename>/etc/profile</filename> or 364 <filename>.bash_profile</filename> files, but reads the 365 <filename>.bashrc</filename> file instead. Create this latter file now:</para> 364 366 365 367 <screen><userinput>cat > ~/.bashrc << "EOF"</userinput> … … 402 404 during the rest of the building process.</para> 403 405 404 <para>Finally, source the just-created profile so that we're all set to begin405 building the temporary tools that will support us in later chapters.</para>406 <para>Finally, to have our environment fully prepared for building the 407 temporary tools, source the just-created profile:</para> 406 408 407 409 <screen><userinput>source ~/.bash_profile</userinput></screen> … … 437 439 source and build directories from the first pass or otherwise accidentally 438 440 deleted them or just don't have access to them, don't worry, all is not lost. 439 Just ignore the above command. The result is a small chance of subsequent440 programs linking against libraries on the host. This is not ideal, however, 441 Just ignore the above command. The result is a small chance of the subsequent 442 testing programs linking against libraries on the host. This is not ideal, but 441 443 it's not a major problem. The situation is corrected when we install the 442 second pass of Binutils later on.</para></note>444 second pass of Binutils a bit further on.</para></note> 443 445 444 446 <para>Now that the adjusted linker is installed, you have to remove the
Note:
See TracChangeset
for help on using the changeset viewer.