- Timestamp:
- 02/19/2005 10:16:42 PM (19 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.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, 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:
- 3d31fc4
- Parents:
- 2f9131f
- Location:
- chapter04
- Files:
-
- 6 edited
-
aboutlfs.xml (modified) (1 diff)
-
aboutsbus.xml (modified) (1 diff)
-
abouttestsuites.xml (modified) (1 diff)
-
addinguser.xml (modified) (1 diff)
-
creatingtoolsdir.xml (modified) (1 diff)
-
settingenviron.xml (modified) (2 diffs)
Legend:
- Unmodified
- Added
- Removed
-
chapter04/aboutlfs.xml
r2f9131f r81fd230 8 8 <?dbhtml filename="aboutlfs.html"?> 9 9 10 <para>See testing</para> 10 <para>Throughout this book, the environment variable <envar>LFS</envar> will 11 be used 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 <envar>LFS</envar> variable is set up properly with:</para> 14 15 <screen><userinput>echo $LFS</userinput></screen> 16 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 22 <screen><userinput>export LFS=/mnt/lfs</userinput></screen> 23 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> 29 30 <para>Do not forget to check that <envar>$LFS</envar> 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> 11 33 12 34 </sect1> 35 -
chapter04/aboutsbus.xml
r2f9131f r81fd230 8 8 <?dbhtml filename="aboutsbus.html"?> 9 9 10 <para>See testing</para> 10 <para>Many 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 Static Build Unit (SBU) measure will be 17 used instead.</para> 18 19 <para>The SBU measure works as follows. 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 Build Unit 23 or SBU. All other compile times will be expressed relative to this 24 time.</para> 25 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 shorter than the one 31 for Binutils.</para> 32 33 <para>Please note that if the system compiler on the host is GCC-2.x 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 Symmetric Multi-Processor (SMP)-based machines.</para> 39 40 <para>To view actual timings for a number of specific machines, we recommend 41 <ulink url="&lfs-root;~bdubbs/"/>.</para> 42 43 <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 minutes in some cases.</para> 11 48 12 49 </sect1> 50 -
chapter04/abouttestsuites.xml
r2f9131f r81fd230 8 8 <?dbhtml filename="abouttestsuites.html"?> 9 9 10 <para>See testing</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 <quote>sanity 12 check</quote> 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> 16 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> 23 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> 35 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 <systemitem class="filesystem">devpts</systemitem> file system set up 41 correctly. This issue is discussed in greater detail in <xref 42 linkend="chapter-temporary-tools"/>.</para> 43 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 expected. This site is valid for all tests throughout this 47 book.</para> 11 48 12 49 </sect1> 50 -
chapter04/addinguser.xml
r2f9131f r81fd230 8 8 <?dbhtml filename="addinguser.html"?> 9 9 10 <para>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> 11 19 12 20 <screen><userinput>groupadd lfs 13 21 useradd -s /bin/bash -g lfs -m -k /dev/null lfs</userinput></screen> 14 22 23 <para>The meaning of the command line options:</para> 24 25 <variablelist> 26 <varlistentry> 27 <term><parameter>-s /bin/bash</parameter></term> 28 <listitem><para>This makes 29 <command>bash</command> the default shell for user 30 <emphasis>lfs</emphasis>.</para></listitem> 31 </varlistentry> 32 33 <varlistentry> 34 <term><parameter>-g lfs</parameter></term> 35 <listitem><para>This option adds user <emphasis>lfs</emphasis> to group 36 <emphasis>lfs</emphasis>.</para></listitem> 37 </varlistentry> 38 39 <varlistentry> 40 <term><parameter>-m</parameter></term> 41 <listitem><para>This creates a home 42 directory for <emphasis>lfs</emphasis>.</para></listitem> 43 </varlistentry> 44 45 <varlistentry> 46 <term><parameter>-k /dev/null</parameter></term> 47 <listitem><para>This parameter 48 prevents possible copying of files from a skeleton directory (default 49 is <filename class="directory">/etc/skel</filename>) by changing the input location to 50 the special null device.</para></listitem> 51 </varlistentry> 52 53 <varlistentry> 54 <term><parameter>lfs</parameter></term> 55 <listitem><para>This is the actual name for the created group and 56 user.</para></listitem> 57 </varlistentry> 58 </variablelist> 59 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), give <emphasis>lfs</emphasis> a password:</para> 65 15 66 <screen><userinput>passwd lfs</userinput></screen> 67 68 <para>Grant <emphasis>lfs</emphasis> full access to 69 <filename class="directory">$LFS/tools</filename> by making 70 <emphasis>lfs</emphasis> the directory owner:</para> 16 71 17 72 <screen><userinput>chown lfs $LFS/tools</userinput></screen> 18 73 74 <para>If a separate working directory was created as suggested, give 75 user <emphasis>lfs</emphasis> ownership of this directory:</para> 76 19 77 <screen><userinput>chown lfs $LFS/sources</userinput></screen> 78 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> 20 82 21 83 <screen><userinput>su - lfs</userinput></screen> 22 84 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> 89 23 90 </sect1> 91 -
chapter04/creatingtoolsdir.xml
r2f9131f r81fd230 8 8 <?dbhtml filename="creatingtoolsdir.html"?> 9 9 10 <para>All programs compiled in <xref 11 linkend="chapter-temporary-tools"/> will be installed under <filename 12 class="directory">$LFS/tools</filename> to keep them separate from the 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"/>).</para> 20 21 <para>Create the required directory by running the following as 22 <emphasis>root</emphasis>:</para> 23 10 24 <screen><userinput>mkdir $LFS/tools</userinput></screen> 25 26 <para>The next step is to create a <filename class="symlink">/tools</filename> 27 symlink on the host system. This will point to the newly-created directory on 28 the LFS partition. Run this command as <emphasis>root</emphasis> as 29 well:</para> 11 30 12 31 <screen><userinput>ln -s $LFS/tools /</userinput></screen> 13 32 33 <note><para>The above command is correct. The <command>ln</command> 34 command has a few syntactic variations, so be sure to check the info 35 and man pages before reporting what you may think is an 36 error.</para></note> 37 38 <para>The created symlink enables the toolchain to be compiled so that 39 it always refers to <filename class="directory">/tools</filename>, 40 meaning that the compiler, assembler, and linker will work both in 41 this chapter (when we are still using some tools from the host) and in 42 the next (when we are <quote>chrooted</quote> to the LFS 43 partition).</para> 44 14 45 </sect1> 46 -
chapter04/settingenviron.xml
r2f9131f r81fd230 8 8 <?dbhtml filename="settingenvironment.html"?> 9 9 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 10 15 <screen><userinput>cat > ~/.bash_profile << "EOF" 11 16 <literal>exec env -i HOME=$HOME TERM=$TERM PS1='\u:\w\$ ' /bin/bash</literal> 12 17 EOF</userinput></screen> 18 19 <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 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 <envar>HOME</envar>, <envar>TERM</envar>, and 28 <envar>PS1</envar> 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 ensuring a clean environment.</para> 32 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> 13 38 14 39 <screen><userinput>cat > ~/.bashrc << "EOF" … … 21 46 EOF</userinput></screen> 22 47 48 <para>The <command>set +h</command> command turns off 49 <command>bash</command>'s hash function. Hashing is ordinarily a useful 50 feature—<command>bash</command> uses a hash table to remember the 51 full path of executable files to avoid searching the <envar>PATH</envar> time 52 and 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 <envar>PATH</envar> when a program is 55 to be run. As such, the shell will find the 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 in a different location.</para> 59 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> 65 66 <para>The <envar>LFS</envar> variable should be set to the 67 chosen mount point.</para> 68 69 <para>The <envar>LC_ALL</envar> 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 <envar>LC_ALL</envar> 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. Setting <envar>LC_ALL</envar> to <quote>POSIX</quote> 76 or <quote>C</quote> (the two are equivalent) ensures that 77 everything will work as expected in the chroot environment.</para> 78 79 <para>By putting <filename class="directory">/tools/bin</filename> 80 ahead of the standard <envar>PATH</envar>, all the programs installed in <xref 81 linkend="chapter-temporary-tools"/> are picked up by the shell 82 immediately after their installation. This, combined with turning off 83 hashing, limits the risk that old programs from 84 the host are being used when they should not be used any 85 longer.</para> 86 87 <para>Finally, to have the environment fully prepared for building the 88 temporary tools, source the just-created user profile:</para> 89 23 90 <screen><userinput>source ~/.bash_profile</userinput></screen> 24 91 25 92 </sect1> 93
Note:
See TracChangeset
for help on using the changeset viewer.
