- Timestamp:
- 08/29/2004 06:36:34 PM (20 years ago)
- Branches:
- 6.0
- Children:
- 8b320e7
- Parents:
- ec0a37e6
- Location:
- chapter04
- Files:
-
- 6 edited
-
aboutlfs.xml (modified) (1 diff)
-
aboutsbus.xml (modified) (3 diffs)
-
abouttestsuites.xml (modified) (3 diffs)
-
addinguser.xml (modified) (5 diffs)
-
creatingtoolsdir.xml (modified) (1 diff)
-
settingenviron.xml (modified) (6 diffs)
Legend:
- Unmodified
- Added
- Removed
-
chapter04/aboutlfs.xml
rec0a37e6 r69993f4 28 28 processes the command line.</para> 29 29 30 <para>Do n't forget to check that <quote>$LFS</quote> is set whenever30 <para>Do not forget to check that <quote>$LFS</quote> is set whenever 31 31 you leave and reenter the current working environment (as when doing a 32 32 <quote>su</quote> to <emphasis>root</emphasis> or another user).</para> -
chapter04/aboutsbus.xml
rec0a37e6 r69993f4 8 8 <?dbhtml filename="aboutsbus.html"?> 9 9 10 <para>M ostpeople would like to know beforehand approximately how long10 <para>Many people would like to know beforehand approximately how long 11 11 it takes to compile and install each package. Because Linux From 12 12 Scratch can be built on many different systems, it is impossible to … … 14 14 take approximately 20 minutes on the fastest systems, but could take 15 15 up to three days on slower systems! Instead of providing actual times, 16 the <emphasis>Static Binutils Unit</emphasis>(SBU) measure will be16 the Static Binutils Unit (SBU) measure will be 17 17 used instead.</para> 18 18 19 <para>The SBU measure works like this?the first package to be compiled19 <para>The SBU measure works as follows. The first package to be compiled 20 20 from this book is the statically-linked Binutils in <xref 21 21 linkend="chapter-temporary-tools"/>. The time it takes to compile … … 28 28 install the static Binutils, it will take 29 29 <emphasis>approximately</emphasis> 45 minutes to build this example 30 package. Fortunately, most build times are muchshorter than the one30 package. Fortunately, most build times are shorter than the one 31 31 for Binutils.</para> 32 32 33 <para>Please note that if the system compiler on the host is GCC-2based, the33 <para>Please note that if the system compiler on the host is gcc-2.x based, the 34 34 SBUs listed may be somewhat understated. This is because the SBU is 35 35 based on the very first package, compiled with the old GCC, while the 36 36 rest of the system is compiled with the newer GCC-&gcc-version; (which is 37 37 known to be approximately 30 percent slower). SBUs are also not 38 highly accurate for S MP-based machines.</para>38 highly accurate for Symmetric Multi-Processor (SMP)-based machines.</para> 39 39 40 40 <para>To view actual timings for specific machines, we recommend 41 41 <ulink url="&lfs-root;~bdubbs/"/>.</para> 42 42 43 <para>In general, SBUs are inaccurate because they depend on many44 factors, not just the GCC version. The only reason they are provided45 is to give some kind of indicationof how long it might take to46 install a package, but the numbers can be offby as much as dozens of43 <para>In general, SBUs are not very accurate because they depend on many 44 factors, not just the GCC version. They are provided 45 here to give an estimate of how long it might take to 46 install a package, but the numbers can vary by as much as dozens of 47 47 minutes in some cases.</para> 48 48 -
chapter04/abouttestsuites.xml
rec0a37e6 r69993f4 9 9 10 10 <para>Most packages provide a test suite. Running the test suite for a 11 newly built package is a good idea because it can provide a ?sanity12 check ?indicating that everything compiled correctly. A test suite11 newly built package is a good idea because it can provide a <quote>sanity 12 check</quote> indicating that everything compiled correctly. A test suite 13 13 that passes its set of checks usually proves that the package is 14 14 functioning as the developer intended. It does not, however, guarantee … … 16 16 17 17 <para>Some test suites are more important than others. For example, 18 the test suites for the core toolchain packages ?GCC, Binutils, and19 Glibc ?are of the utmost importance due to their central role in a18 the test suites for the core toolchain packages—GCC, Binutils, and 19 Glibc—are of the utmost importance due to their central role in a 20 20 properly functioning system. The test suites for GCC and Glibc can 21 21 take a very long time to complete, especially on slower hardware, but … … 44 44 <para>Sometimes package test suites will give false failures. Consult 45 45 the LFS Wiki at <ulink url="&wiki-root;"/> to verify that these 46 failures are normal. This site is valid for all tests throughout this46 failures are expected. This site is valid for all tests throughout this 47 47 book.</para> 48 48 -
chapter04/addinguser.xml
rec0a37e6 r69993f4 5 5 ]> 6 6 <sect1 id="ch-tools-addinguser"> 7 <title>Adding the lfsUser</title>7 <title>Adding the LFS User</title> 8 8 <?dbhtml filename="addinguser.html"?> 9 9 … … 33 33 <varlistentry> 34 34 <term><parameter>-g lfs</parameter></term> 35 <listitem><para>This adds user <emphasis>lfs</emphasis> to group35 <listitem><para>This option adds user <emphasis>lfs</emphasis> to group 36 36 <emphasis>lfs</emphasis></para></listitem> 37 37 </varlistentry> … … 53 53 <varlistentry> 54 54 <term><parameter>lfs</parameter></term> 55 <listitem><para>Th e actual name for the created group and55 <listitem><para>This is the actual name for the created group and 56 56 user</para></listitem> 57 57 </varlistentry> … … 60 60 <para>To log in as <emphasis>lfs</emphasis> (as opposed to switching 61 61 to user <emphasis>lfs</emphasis> when 62 logged in as <emphasis>root</emphasis> --which does not require the62 logged in as <emphasis>root</emphasis>, which does not require the 63 63 <emphasis>lfs</emphasis> user to have a 64 password in that case), give <emphasis>lfs</emphasis> a password:</para>64 password), give <emphasis>lfs</emphasis> a password:</para> 65 65 66 66 <screen><userinput>passwd lfs</userinput></screen> … … 73 73 74 74 <para>If a separate working directory was created as suggested, give 75 user lfs ownership of this directory too:</para>75 user lfs ownership of this directory:</para> 76 76 77 77 <screen><userinput>chown lfs $LFS/sources</userinput></screen> -
chapter04/creatingtoolsdir.xml
rec0a37e6 r69993f4 17 17 also prevents these programs from ending up in the host production 18 18 directories (easy to do by accident in <xref 19 linkend="chapter-temporary-tools"/>), which could be a very bad 20 thing.</para> 19 linkend="chapter-temporary-tools"/>).</para> 21 20 22 21 <para>Create the required directory by running the following as -
chapter04/settingenviron.xml
rec0a37e6 r69993f4 5 5 ]> 6 6 <sect1 id="ch-tools-settingenviron"> 7 <title>Setting up the environment</title>7 <title>Setting Up the Environment</title> 8 8 <?dbhtml filename="settingenvironment.html"?> 9 9 … … 17 17 EOF</userinput></screen> 18 18 19 <para> Normally when logged on as user <emphasis>lfs</emphasis>, the20 initial shell is a <emphasis>login</emphasis> shell which reads the21 <filename>/etc/profile</filename> of yourhost (probably containing19 <para>When logged on as user <emphasis>lfs</emphasis>, the 20 initial shell is usually a <emphasis>login</emphasis> shell which reads the 21 <filename>/etc/profile</filename> of the host (probably containing 22 22 some settings and environment variables) and then 23 23 <filename>.bash_profile</filename>. The <command>exec env … … 29 29 potentially hazardous environment variables from the host system leak 30 30 into the build environment. The technique used here achieves the goal 31 of en forcing a clean environment.</para>31 of ensuring a clean environment.</para> 32 32 33 33 <para>The new instance of the shell is a <emphasis>non-login</emphasis> … … 48 48 <para>The <command>set +h</command> command turns off 49 49 <command>bash</command>'s hash function. Hashing is 50 ordinarily a useful feature --bash uses a hash table to remember the50 ordinarily a useful feature—bash uses a hash table to remember the 51 51 full pathnames of executable files to avoid searching the PATH time 52 and timeagain to find the same executable. However, the new tools52 and again to find the same executable. However, the new tools 53 53 should be used as soon as they are installed. By switching off the 54 54 hash function, the shell will always search the PATH when a program is 55 requested to be run. As such, the shell will find ournewly compiled55 to be run. As such, the shell will find the newly compiled 56 56 tools in <filename class="directory">$LFS/tools</filename> as soon as 57 57 they are available without remembering a previous version of the same 58 program (name wise)in a different location.</para>58 program in a different location.</para> 59 59 60 60 <para>Setting the user file-creation mask (umask) to 022 ensures that newly … … 73 73 <quote>POSIX</quote> or <quote>C</quote> (during this chapter) may 74 74 cause issues if you exit the chroot environment and wish to return 75 later. By setting <emphasis>LC_ALL</emphasis> to <quote>POSIX</quote>76 or <quote>C</quote> (the two are equivalent) , we ensurethat75 later. Setting <emphasis>LC_ALL</emphasis> to <quote>POSIX</quote> 76 or <quote>C</quote> (the two are equivalent) ensures that 77 77 everything will work as expected in the chroot environment.</para> 78 78 … … 80 80 ahead of the standard PATH, all the programs installed in <xref 81 81 linkend="chapter-temporary-tools"/> are picked up by the shell 82 im emdiately after their installation. This coupled with the fact that83 hashing has been turned off, there is norisk that old programs from82 immediately after their installation. This, combined with turning off 83 hashing, limits the risk that old programs from 84 84 the host are being used when they should not be used any 85 85 longer.</para>
Note:
See TracChangeset
for help on using the changeset viewer.
