- Timestamp:
- 08/08/2004 02:10:22 AM (20 years ago)
- Branches:
- 6.0
- Children:
- 6e41459
- Parents:
- 843710f
- Location:
- chapter04
- Files:
-
- 6 edited
-
aboutlfs.xml (modified) (1 diff)
-
aboutsbus.xml (modified) (1 diff)
-
abouttestsuites.xml (modified) (1 diff)
-
addinguser.xml (modified) (3 diffs)
-
creatingtoolsdir.xml (modified) (1 diff)
-
settingenviron.xml (modified) (3 diffs)
Legend:
- Unmodified
- Added
- Removed
-
chapter04/aboutlfs.xml
r843710f r78349b7 8 8 <?dbhtml filename="aboutlfs.html"?> 9 9 10 <para>Throughout this book the environment variable LFS will be used several11 times. It is paramount that this variable is always defined. It should be set 12 to the mount point you chose for your LFS partition. Check that your LFS 13 variable is set up properly with:</para>10 <para>Throughout this book, the environment variable LFS will be used 11 several times. It is paramount that this variable is always defined. 12 It should be set to the mount point chosen for the LFS partition. 13 Check that the LFS variable is set up properly with:</para> 14 14 15 15 <screen><userinput>echo $LFS</userinput></screen> 16 16 17 <para>Make sure the output shows the path to yourLFS partition's mount18 point, which is <filename class="directory">/mnt/lfs</filename> if you19 followed our example. If the output is wrong, you can always set the variable20 with:</para>17 <para>Make sure the output shows the path to the LFS partition's mount 18 point, which is <filename class="directory">/mnt/lfs</filename> if the 19 provided example was followed. If the output is incorrect, the 20 variable can be set with:</para> 21 21 22 22 <screen><userinput>export LFS=/mnt/lfs</userinput></screen> 23 23 24 <para>Having this variable set means that if you are told to run a command like 25 <command>mkdir $LFS/tools</command>, you can type it literally. Your shell 26 will replace <quote>$LFS</quote> with <quote>/mnt/lfs</quote> (or whatever 27 you set the variable to) when it processes the command line.</para> 24 <para>Having this variable set is beneficial in that commands such as 25 <command>mkdir $LFS/tools</command> can be typed literally. The shell 26 will automatically replace <quote>$LFS</quote> with 27 <quote>/mnt/lfs</quote> (or whatever the variable was set to) when it 28 processes the command line.</para> 28 29 29 <para>Don't forget to check that <quote>$LFS</quote> is set whenever you leave and30 reenter the environment (as when doing a <quote>su</quote> to root or another user). 31 < /para>30 <para>Don't forget to check that <quote>$LFS</quote> is set whenever 31 you leave and reenter the current working environment (as when doing a 32 <quote>su</quote> to <emphasis>root</emphasis> or another user).</para> 32 33 33 34 </sect1> 35 -
chapter04/aboutsbus.xml
r843710f r78349b7 8 8 <?dbhtml filename="aboutsbus.html"?> 9 9 10 <para>Most people would like to know beforehand approximately how long it11 takes to compile and install each package. But <quote>Linux from Scratch</quote> is built 12 on so many different systems, it is not possible to give actual times that are 13 anywhere near accurate: the biggest package (Glibc) won't take more than 14 t wenty minutes on the fastest systems, but will take something like three days15 on the slowest -- no kidding. So instead of giving actual times, we've come up 16 with the idea of using the <emphasis>Static Binutils Unit</emphasis> 17 (abbreviated to <emphasis>SBU</emphasis>).</para>10 <para>Most people would like to know beforehand approximately how long 11 it takes to compile and install each package. Because Linux From 12 Scratch can be built on many different systems, it is impossible to 13 provide accurate time estimates. The biggest package (Glibc) will 14 take approximately 20 minutes on the fastest systems, but could take 15 up to three days on slower systems! Instead of providing actual times, 16 the <emphasis>Static Binutils Unit</emphasis> (SBU) measure will be 17 used instead.</para> 18 18 19 <para>It works like this: the first package you compile in this book is the 20 statically linked Binutils in <xref linkend="chapter-temporary-tools"/>, and the time it 21 takes to compile this package is what we call the <quote>Static Binutils 22 Unit</quote> or <quote>SBU</quote>. All other compile times will be expressed 23 relative to this time.</para> 19 <para>The SBU measure works like this?the first package to be compiled 20 from this book is the statically-linked Binutils in <xref 21 linkend="chapter-temporary-tools"/>. The time it takes to compile 22 this package is what will be referred to as the Static Binutils Unit 23 or SBU. All other compile times will be expressed relative to this 24 time.</para> 24 25 25 <para>For example, consider a particular package whose compilation time is 4.5 26 SBUs. This means that if on your system it took 10 minutes to compile and 27 install the static Binutils, then you know it will take 28 <emphasis>approximately</emphasis> 45 minutes to build this package. 29 Fortunately, most build times are much shorter than the one of Binutils.</para> 26 <para>For example, consider a package whose compilation time is 4.5 27 SBUs. This means that if a system took 10 minutes to compile and 28 install the static Binutils, it will take 29 <emphasis>approximately</emphasis> 45 minutes to build this example 30 package. Fortunately, most build times are much shorter than the one 31 for Binutils.</para> 30 32 31 <para>Note that if the system compiler on your host is GCC-2 based, the SBUs 32 listed may end up being somewhat understated. This is because the SBU is based 33 on the very first package, compiled with the old GCC, while the rest of the 34 system is compiled with the newer GCC-&gcc-version; which is known to be 35 approximately 30% slower.</para> 33 <para>Please note that if the system compiler on the host is GCC-2 based, the 34 SBUs listed may be somewhat understated. This is because the SBU is 35 based on the very first package, compiled with the old GCC, while the 36 rest of the system is compiled with the newer GCC-&gcc-version; (which is 37 known to be approximately 30 percent slower). SBUs are also not 38 highly accurate for SMP-based machines.</para> 36 39 37 <para>Also note that SBUs don't work well for SMP-based machines. But if you're 38 so lucky as to have multiple processors, chances are that your system is so fast 39 that you won't mind.</para> 40 41 <para>If you wish to see actual timings for specific machines, have a look at 40 <para>To view actual timings for specific machines, we recommend 42 41 <ulink url="&lfs-root;~bdubbs/"/>.</para> 43 42 43 <para>In general, SBUs are inaccurate because they depend on many 44 factors, not just the GCC version. The only reason they are provided 45 is to give some kind of indication of how long it might take to 46 install a package, but the numbers can be off by as much as dozens of 47 minutes in some cases.</para> 48 44 49 </sect1> 50 -
chapter04/abouttestsuites.xml
r843710f r78349b7 5 5 ]> 6 6 <sect1 id="prepare-abouttestsuites"> 7 <title>About the test suites</title>7 <title>About the Test Suites</title> 8 8 <?dbhtml filename="abouttestsuites.html"?> 9 9 10 <para>Most packages provide a test suite. Running the test suite for a newly 11 built package is generally a good idea, as it can provide a nice sanity check 12 that everything compiled correctly. A test suite that passes its set of checks 13 usually proves that the package is functioning as the developer intended. It 14 does not, however, guarantee that the package is totally bug free.</para> 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 ?sanity 12 check? indicating that everything compiled correctly. A test suite 13 that passes its set of checks usually proves that the package is 14 functioning as the developer intended. It does not, however, guarantee 15 that the package is totally bug free.</para> 15 16 16 <para>Some test suites are more important than others. For example, the test 17 suites for the core toolchain packages -- GCC, Binutils, and Glibc -- are of 18 the utmost importance due to their central role in a properly functioning 19 system. But be warned, the test suites for GCC and Glibc can take a very long 20 time to complete, especially on slower hardware.</para> 17 <para>Some test suites are more important than others. For example, 18 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 properly functioning system. The test suites for GCC and Glibc can 21 take a very long time to complete, especially on slower hardware, but 22 are strongly recommended.</para> 21 23 22 <note><para>Experience has shown us that there is little to be gained from running 23 the test suites in <xref linkend="chapter-temporary-tools"/>. There can be no 24 escaping the fact that the host system always exerts some influence on the 25 tests in that chapter, often causing weird and inexplicable failures. Not only 26 that, the tools built in <xref linkend="chapter-temporary-tools"/> are 27 temporary and eventually discarded. For the average reader of this book we 28 recommend <emphasis>not</emphasis> to run the test suites in 29 <xref linkend="chapter-temporary-tools"/>. The instructions for running those test 30 suites are still provided for the benefit of testers and developers, but they 31 are strictly optional for everyone else.</para></note> 24 <note><para>Experience has shown that there is little to be gained 25 from running the test suites in <xref 26 linkend="chapter-temporary-tools"/>. There can be no escaping the fact 27 that the host system always exerts some influence on the tests in that 28 chapter, often causing inexplicable failures. Because the tools built 29 in <xref linkend="chapter-temporary-tools"/> are temporary and 30 eventually discarded, we do not recommend running the test suites in 31 <xref linkend="chapter-temporary-tools"/> for the average reader. The 32 instructions for running those test suites are provided for the 33 benefit of testers and developers, but they are strictly 34 optional.</para></note> 32 35 33 <para>A common problem when running the test suites for Binutils and GCC is 34 running out of pseudo terminals (PTYs for short). The symptom is a very high 35 number of failing tests. This can happen for several reasons, but the most 36 likely cause is that the host system doesn't have the 37 <emphasis>devpts</emphasis> file system set up correctly. We'll discuss this in 38 more detail later on in <xref linkend="chapter-temporary-tools"/>.</para> 36 <para>A common issue with running the test suites for Binutils and GCC 37 is running out of pseudo terminals (PTYs). This can result in a high 38 number of failing tests. This may happen for several reasons, but the 39 most likely cause is that the host system does not have the 40 <emphasis>devpts</emphasis> file system set up correctly. This issue 41 is discussed in greater detail in <xref 42 linkend="chapter-temporary-tools"/>.</para> 39 43 40 <para>Sometimes package test suites will give false failures. You can 41 consult the LFS Wiki at <ulink url="&wiki-root;"/> to verify that these 42 failures are normal. This applies to all tests throughout the book.</para> 44 <para>Sometimes package test suites will give false failures. Consult 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 this 47 book.</para> 43 48 44 49 </sect1> 50 -
chapter04/addinguser.xml
r843710f r78349b7 5 5 ]> 6 6 <sect1 id="ch-tools-addinguser"> 7 <title>Adding the user lfs</title>7 <title>Adding the lfs User</title> 8 8 <?dbhtml filename="addinguser.html"?> 9 9 10 <para>When logged in as <emphasis>root</emphasis>, making a single mistake 11 can damage or even wreck your system. Therefore we recommend that you 12 build the packages in this chapter as an unprivileged user. You could 13 of course use your own user name, but to make it easier to set up a clean 14 work environment we'll create a new user <emphasis>lfs</emphasis> as a 15 member of a new group (also named <emphasis>lfs</emphasis>) and 16 use this one during the installation process. As <emphasis>root</emphasis>, 17 issue the following commands to add the new user:</para> 10 <para>When logged in as user <emphasis>root</emphasis>, making a 11 single mistake can damage or destroy a system. Therefore, we recommend 12 building the packages in this chapter as an unprivileged user. You 13 could use your own user name, but to make it easier to set up a clean 14 work environment, create a new user called <emphasis>lfs</emphasis> as 15 a member of a new group (also named <emphasis>lfs</emphasis>) and use 16 this user during the installation process. As 17 <emphasis>root</emphasis>, issue the following commands to add the new 18 user:</para> 18 19 19 20 <screen><userinput>groupadd lfs 20 21 useradd -s /bin/bash -g lfs -m -k /dev/null lfs</userinput></screen> 21 22 22 <para>The meaning of the switches:</para>23 <para>The meaning of the command line options:</para> 23 24 24 25 <variablelist> … … 49 50 the special null device.</para></listitem> 50 51 </varlistentry> 52 53 <varlistentry> 54 <term><parameter>lfs</parameter></term> 55 <listitem><para>The actual name for the created group and 56 user</para></listitem> 57 </varlistentry> 51 58 </variablelist> 52 59 53 <para>If you want to be able to log in as <emphasis>lfs</emphasis>, then give 54 <emphasis>lfs</emphasis> a password:</para> 60 <para>To log in as <emphasis>lfs</emphasis> (as opposed to switching 61 to user <emphasis>lfs</emphasis> when 62 logged in as <emphasis>root</emphasis> -- which does not require the 63 <emphasis>lfs</emphasis> user to have a 64 password in that case), give <emphasis>lfs</emphasis> a password:</para> 55 65 56 66 <screen><userinput>passwd lfs</userinput></screen> 57 67 58 <para> and grant <emphasis>lfs</emphasis> full access to68 <para>Grant <emphasis>lfs</emphasis> full access to 59 69 <filename class="directory">$LFS/tools</filename> by making 60 70 <emphasis>lfs</emphasis> the directory owner:</para> … … 62 72 <screen><userinput>chown lfs $LFS/tools</userinput></screen> 63 73 64 <para>If you made a separate working directory as suggested, give user65 <emphasis>lfs</emphasis>ownership of this directory too:</para>74 <para>If a separate working directory was created as suggested, give 75 user lfs ownership of this directory too:</para> 66 76 67 77 <screen><userinput>chown lfs $LFS/sources</userinput></screen> 68 78 69 <para>Next, login as user <emphasis>lfs</emphasis>. This can be done via a70 vi rtual console, through a display manager, or with the following substitute71 user command:</para>79 <para>Next, login as user <emphasis>lfs</emphasis>. This can be done 80 via a virtual console, through a display manager, or with the 81 following substitute user command:</para> 72 82 73 83 <screen><userinput>su - lfs</userinput></screen> 74 84 75 <para>The <quote><parameter>-</parameter></quote> instructs <command>su</command> to 76 start a <emphasis>login</emphasis> shell.</para> 85 <para>The <quote><parameter>-</parameter></quote> instructs 86 <command>su</command> to start a login shell as opposed to a non-login 87 shell. The difference between these two types of shells can be found 88 in detail in the Bash man and info pages.</para> 77 89 78 90 </sect1> 91 -
chapter04/creatingtoolsdir.xml
r843710f r78349b7 5 5 ]> 6 6 <sect1 id="ch-tools-creatingtoolsdir"> 7 <title>Creating the $LFS/tools directory</title>7 <title>Creating the $LFS/tools Directory</title> 8 8 <?dbhtml filename="creatingtoolsdir.html"?> 9 9 10 <para>All programs compiled in <xref linkend="chapter-temporary-tools"/> will be installed under <filename 10 <para>All programs compiled in <xref 11 linkend="chapter-temporary-tools"/> will be installed under <filename 11 12 class="directory">$LFS/tools</filename> to keep them separate from the 12 programs compiled in <xref linkend="chapter-building-system"/>. The programs compiled here are only 13 temporary tools and won't be a part of the final LFS system and by keeping them 14 in a separate directory, we can later easily throw them away. This also 15 helps prevent them from ending up in your host's production directories 16 (easy to do in <xref linkend="chapter-temporary-tools"/>), which could be a very bad thing.</para> 13 programs compiled in <xref linkend="chapter-building-system"/>. The 14 programs compiled here are temporary tools and will not be a part of 15 the final LFS system. By keeping these programs in a separate 16 directory, they can easily be discarded later after their use. This 17 also prevents these programs from ending up in the host production 18 directories (easy to do by accident in <xref 19 linkend="chapter-temporary-tools"/>), which could be a very bad 20 thing.</para> 17 21 18 <para>Later on you might wish to search through the binaries of your system to 19 see what files they make use of or link against. To make this searching easier 20 you may want to choose a unique name for the directory in which the temporary 21 tools are stored. Instead of the simple <quote>tools</quote> you could use 22 something like <quote>tools-for-lfs</quote>. However, you'll need to be careful 23 to adjust all references to <quote>tools</quote> throughout the book -- 24 including those in any patches, notably the GCC Specs Patch.</para> 25 26 <para>Create the required directory by running the following:</para> 22 <para>Create the required directory by running the following as 23 <emphasis>root</emphasis>:</para> 27 24 28 25 <screen><userinput>mkdir $LFS/tools</userinput></screen> 29 26 30 <para>The next step is to create a <filename>/tools</filename> symlink on 31 your <emphasis>host</emphasis> system. It will point to the directory we just created on the LFS 32 partition:</para> 27 <para>The next step is to create a <filename>/tools</filename> symlink 28 on the host system. This will point to the newly-created directory on 29 the LFS partition. Run this command as <emphasis>root</emphasis> as 30 well:</para> 33 31 34 32 <screen><userinput>ln -s $LFS/tools /</userinput></screen> 35 33 36 <note><para>The above command is correct. The <command>ln</command> command 37 has a few syntactic variations, so be sure to check the info page before 38 reporting what you may think is an error.</para></note> 34 <note><para>The above command is correct. The <command>ln</command> 35 command has a few syntactic variations, so be sure to check the info 36 and man pages before reporting what you may think is an 37 error.</para></note> 39 38 40 <para>The created symlink enables us to compile our toolchain so that it always 41 refers to <filename class="directory">/tools</filename>, meaning that the compiler, assembler 42 and linker will work both in this chapter (when we are still using some tools 43 from the host) <emphasis>and</emphasis> in the next (when we are <quote>chrooted</quote> to 44 the LFS partition).</para> 39 <para>The created symlink enables the toolchain to be compiled so that 40 it always refers to <filename class="directory">/tools</filename>, 41 meaning that the compiler, assembler, and linker will work both in 42 this chapter (when we are still using some tools from the host) and in 43 the next (when we are <quote>chrooted</quote> to the LFS 44 partition).</para> 45 45 46 46 </sect1> 47 -
chapter04/settingenviron.xml
r843710f r78349b7 8 8 <?dbhtml filename="settingenvironment.html"?> 9 9 10 <para> We're going to set up a good working environment by creating two new11 startup files for the <command>bash</command> shell. While logged in as 12 user <emphasis>lfs</emphasis>, issue the following command to create a new 13 <filename>.bash_profile</filename>:</para>10 <para>Set up a good working environment by creating two new startup 11 files for the <command>bash</command> shell. While logged in as user 12 <emphasis>lfs</emphasis>, issue the 13 following command to create a new <filename>.bash_profile</filename>:</para> 14 14 15 15 <screen><userinput>cat > ~/.bash_profile << "EOF" … … 17 17 EOF</userinput></screen> 18 18 19 <para>Normally, when you log on as user <emphasis>lfs</emphasis>, 20 the initial shell is a <emphasis>login</emphasis> shell which reads the 21 <filename>/etc/profile</filename> of your host (probably containing some 22 settings of environment variables) and then <filename>.bash_profile</filename>. 23 The <command>exec env -i ... /bin/bash</command> command in the latter file 24 replaces the running shell with a new one with a completely empty environment, 25 except for the HOME, TERM and PS1 variables. This ensures that no unwanted and 26 potentially hazardous environment variables from the host system leak into our 27 build environment. The technique used here is a little strange, but it achieves 28 the goal of enforcing a clean environment.</para> 19 <para>Normally when logged on as user <emphasis>lfs</emphasis>, the 20 initial shell is a <emphasis>login</emphasis> shell which reads the 21 <filename>/etc/profile</filename> of your host (probably containing 22 some settings and environment variables) and then 23 <filename>.bash_profile</filename>. The <command>exec env 24 -i.../bin/bash</command> command in the 25 <filename>.bash_profile</filename> file replaces the running shell 26 with a new one with a completely empty environment, except for the 27 <emphasis>HOME</emphasis>, <emphasis>TERM</emphasis>, and 28 <emphasis>PS1</emphasis> variables. This ensures that no unwanted and 29 potentially hazardous environment variables from the host system leak 30 into the build environment. The technique used here achieves the goal 31 of enforcing a clean environment.</para> 29 32 30 <para>The new instance of the shell is a <emphasis>non-login</emphasis> shell, 31 which doesn't read the <filename>/etc/profile</filename> or 32 <filename>.bash_profile</filename> files, but reads the 33 <filename>.bashrc</filename> file instead. Create this latter file now:</para> 33 <para>The new instance of the shell is a <emphasis>non-login</emphasis> 34 shell, which does not read the <filename>/etc/profile</filename> or 35 <filename>.bash_profile</filename> files, but rather reads the 36 <filename>.bashrc</filename> file instead. Create the 37 <filename>.bashrc</filename> file now:</para> 34 38 35 39 <screen><userinput>cat > ~/.bashrc << "EOF" … … 43 47 44 48 <para>The <command>set +h</command> command turns off 45 <command>bash</command>'s hash function. Normally hashing is a useful 46 feature: <command>bash</command> uses a hash table to remember the 47 full pathnames of executable files to avoid searching the PATH time and time 48 again to find the same executable. However, we'd like the new tools to be 49 used as soon as they are installed. By switching off the hash function, our 50 <quote>interactive</quote> commands (<command>make</command>, 51 <command>patch</command>, <command>sed</command>, 52 <command>cp</command> and so forth) will always use 53 the newest available version during the build process.</para> 49 <command>bash</command>'s hash function. Hashing is 50 ordinarily a useful feature -- bash uses a hash table to remember the 51 full pathnames of executable files to avoid searching the PATH time 52 and time again to find the same executable. However, the new tools 53 should be used as soon as they are installed. By switching off the 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 our newly compiled 56 tools in <filename class="directory">$LFS/tools</filename> as soon as 57 they are available without remembering a previous version of the same 58 program (name wise) in a different location.</para> 54 59 55 <para>Setting the user file-creation mask to 022 ensures that newly created 56 files and directories are only writable for their owner, but readable and 57 executable for anyone.</para> 60 <para>Setting the user file-creation mask (umask) to 022 ensures that newly 61 created files and directories are only writable by their owner, but 62 are readable and executable by anyone (assuming default modes are used 63 by the open(2) system call, new files will end up with permission mode 64 644 and directories with mode 755).</para> 58 65 59 <para>The LFS variable should of course be set to the mount point you60 chose .</para>66 <para>The <emphasis>LFS</emphasis> variable should be set to the 67 chosen mount point.</para> 61 68 62 <para>The LC_ALL variable controls the localization of certain programs, 63 making their messages follow the conventions of a specified country. If your 64 host system uses a version of Glibc older than 2.2.4, 65 having LC_ALL set to something other than <quote>POSIX</quote> or 66 <quote>C</quote> during this chapter may cause trouble if you exit the chroot 67 environment and wish to return later. By setting LC_ALL to <quote>POSIX</quote> 68 (or <quote>C</quote>, the two are equivalent) we ensure that 69 <para>The <emphasis>LC_ALL</emphasis> variable controls the 70 localization of certain programs, making their messages follow the 71 conventions of a specified country. If the host system uses a version 72 of Glibc older than 2.2.4, having LC_ALL set to something other than 73 <quote>POSIX</quote> or <quote>C</quote> (during this chapter) may 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 ensure that 69 77 everything will work as expected in the chroot environment.</para> 70 78 71 <para>We prepend <filename class="directory">/tools/bin</filename> to the standard PATH so 72 that, as we move along through this chapter, the tools we build will get used 73 during the rest of the building process.</para> 79 <para>By putting <filename class="directory">/tools/bin</filename> 80 ahead of the standard PATH, all the programs installed in <xref 81 linkend="chapter-temporary-tools"/> are picked up by the shell 82 imemdiately after their installation. This coupled with the fact that 83 hashing has been turned off, there is no risk that old programs from 84 the host are being used when they should not be used any 85 longer.</para> 74 86 75 <para>Finally, to have ourenvironment fully prepared for building the76 temporary tools, source the just-created profile:</para>87 <para>Finally, to have the environment fully prepared for building the 88 temporary tools, source the just-created user profile:</para> 77 89 78 90 <screen><userinput>source ~/.bash_profile</userinput></screen> 79 91 80 92 </sect1> 93
Note:
See TracChangeset
for help on using the changeset viewer.
