Changeset 673b0d8 for chapter04


Ignore:
Timestamp:
05/03/2004 10:59:46 AM (20 years ago)
Author:
Matthew Burgess <matthew@…>
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:
0c43171, 2ec64b3, a4a675f
Parents:
287ea55
Message:
  • Merged newxml into HEAD

git-svn-id: ​http://svn.linuxfromscratch.org/LFS/trunk/BOOK@3435 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689

Location:
chapter04
Files:
6 added
1 edited

Legend:

Unmodified
Added
Removed

  • chapter04/chapter04.xml

    r287ea55 r673b0d8  
    1 <chapter id="chapter-preparation" xreflabel="Chapter 4">
    2 <title>Last preparations</title>
    3 <?dbhtml filename="chapter04.html" dir="chapter04"?>
     1<?xml version="1.0" encoding="ISO-8859-1"?>
     2<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN" "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [
     3  <!ENTITY % general-entities SYSTEM "../general.ent">
     4  %general-entities;
     5]>
     6<chapter id="chapter-final-preps" xreflabel="Chapter 4">
     7<?dbhtml dir="chapter04"?>
     8<title>Final Preparations</title>
     9<?dbhtml filename="chapter04.html"?>
    410
    511
    6 <sect1 id="prepare-aboutlfs">
    7 <title>About $LFS</title>
    8 <?dbhtml filename="aboutlfs.html" dir="chapter04"?>
    9 
    10 <para>Throughout this book the environment variable LFS will be used several
    11 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>
    14 
    15 <screen><userinput>echo $LFS</userinput></screen>
    16 
    17 <para>Make sure the output shows the path to your LFS partition's mount
    18 point, which is <filename class="directory">/mnt/lfs</filename> if you
    19 followed our example. If the output is wrong, you can always set the variable
    20 with:</para>
    21 
    22 <screen><userinput>export LFS=/mnt/lfs</userinput></screen>
    23 
    24 <para>Having this variable set means that if you are told to run a command like
    25 <userinput>mkdir $LFS/tools</userinput>, you can type it literally. Your shell
    26 will replace "$LFS" with "/mnt/lfs" (or whatever you set the variable to) when
    27 it processes the command line.</para>
    28 
    29 </sect1>
    30 
    31 
    32 <sect1 id="prepare-creatingtoolsdir">
    33 <title>Creating the $LFS/tools directory</title>
    34 <?dbhtml filename="creatingtoolsdir.html" dir="chapter05"?>
    35 
    36 <para>All programs compiled in this chapter will be installed under <filename
    37 class="directory">$LFS/tools</filename> to keep them separate from the
    38 programs compiled in the next chapter. The programs compiled here are only
    39 temporary tools and won't be a part of the final LFS system and by keeping them
    40 in a separate directory, we can later easily throw them away.</para>
    41 
    42 <para>Later on you might wish to search through the binaries of your system to
    43 see what files they make use of or link against. To make this searching easier
    44 you may want to choose a unique name for the directory in which the temporary
    45 tools are stored. Instead of the simple "tools" you could use something like
    46 "tools-for-lfs". However, you'll need to be careful to adjust all references to
    47 "tools" throughout the book -- including those in any patches, notably the
    48 GCC Specs Patch.</para>
    49 
    50 <para>Create the required directory by running the following:</para>
    51 
    52 <screen><userinput>mkdir $LFS/tools</userinput></screen>
    53 
    54 <para>The next step is to create a <filename>/tools</filename> symlink on
    55 your host system. It will point to the directory we just created on the LFS
    56 partition:</para>
    57 
    58 <screen><userinput>ln -s $LFS/tools /</userinput></screen>
    59 
    60 <note><para>The above command is correct. The <command>ln</command> command
    61 has a few syntactic variations, so be sure to check the info page before
    62 reporting what you may think is an error.</para></note>
    63 
    64 <para>The created symlink enables us to compile our toolchain so that it always
    65 refers to <filename>/tools</filename>, meaning that the compiler, assembler
    66 and linker will work both in this chapter (when we are still using some tools
    67 from the host) <emphasis>and</emphasis> in the next (when we are chrooted to
    68 the LFS partition).</para>
    69 
    70 </sect1>
    71 
    72 
    73 <sect1 id="prepar-addinguser">
    74 <title>Adding the user lfs</title>
    75 <?dbhtml filename="addinguser.html" dir="chapter05"?>
    76 
    77 <para>When logged in as <emphasis>root</emphasis>, making a single mistake
    78 can damage or even wreck your system. Therefore we recommend that you
    79 build the packages in this chapter as an unprivileged user. You could
    80 of course use your own user name, but to make it easier to set up a clean
    81 work environment we'll create a new user <emphasis>lfs</emphasis> and
    82 use this one during the installation process. As <emphasis>root</emphasis>,
    83 issue the following command to add the new user:</para>
    84 
    85 <screen><userinput>useradd -s /bin/bash -m -k /dev/null lfs</userinput></screen>
    86 
    87 <para>The meaning of the switches:</para>
    88 
    89 <itemizedlist>
    90 <listitem><para><userinput>-s /bin/bash</userinput>: This makes
    91 <userinput>bash</userinput> the default shell for user
    92 <emphasis>lfs</emphasis>.</para></listitem>
    93 
    94 <listitem><para><userinput>-m -k /dev/null</userinput>: These create a home
    95 directory for <emphasis>lfs</emphasis>, while preventing the files from a
    96 possible <filename>/etc/skel</filename> being copied into it.</para></listitem>
    97 </itemizedlist>
    98 
    99 <para>If you want to be able to log in as <emphasis>lfs</emphasis>, then give
    100 this new user a password:</para>
    101 
    102 <screen><userinput>passwd lfs</userinput></screen>
    103 
    104 <para>Now grant this new user <emphasis>lfs</emphasis> full access to
    105 <filename class="directory">$LFS/tools</filename> by giving it ownership
    106 of the directory:</para>
    107 
    108 <screen><userinput>chown lfs $LFS/tools</userinput></screen>
    109 
    110 <para>If you made a separate working directory as suggested, give user
    111 <emphasis>lfs</emphasis> ownership of this directory too:</para>
    112 
    113 <screen><userinput>chown lfs $LFS/sources</userinput></screen>
    114 
    115 <para>Next, login as user <emphasis>lfs</emphasis>. This can be done via a
    116 virtual console, through a display manager, or with the following substitute
    117 user command:</para>
    118 
    119 <screen><userinput>su - lfs</userinput></screen>
    120 
    121 <para>The "<command>-</command>" instructs <command>su</command> to start a
    122 <emphasis>login</emphasis> shell.</para>
    123 
    124 </sect1>
    125 
    126 
    127 <sect1 id="prepare-settingenvironment">
    128 <title>Setting up the environment</title>
    129 <?dbhtml filename="settingenvironment.html" dir="chapter05"?>
    130 
    131 <para>We're going to set up a good working environment by creating two new
    132 startup files for the <command>bash</command> shell. While logged in as
    133 user <emphasis>lfs</emphasis>, issue the following command to create a new
    134 <filename>.bash_profile</filename>:</para>
    135 
    136 <screen><userinput>cat &gt; ~/.bash_profile &lt;&lt; "EOF"</userinput>
    137 exec env -i HOME=$HOME TERM=$TERM PS1='\u:\w\$ ' /bin/bash
    138 <userinput>EOF</userinput></screen>
    139 
    140 <para>Normally, when you log on as user <emphasis>lfs</emphasis>,
    141 the initial shell is a <emphasis>login</emphasis> shell which reads the
    142 <filename>/etc/profile</filename> of your host (probably containing some
    143 settings of environment variables) and then <filename>.bash_profile</filename>.
    144 The <command>exec env -i ... /bin/bash</command> command in the latter file
    145 replaces the running shell with a new one with a completely empty environment,
    146 except for the HOME, TERM and PS1 variables. This ensures that no unwanted and
    147 potentially hazardous environment variables from the host system leak into our
    148 build environment. The technique used here is a little strange, but it achieves
    149 the goal of enforcing a clean environment.</para>
    150 
    151 <para>The new instance of the shell is a <emphasis>non-login</emphasis> shell,
    152 which doesn't read the <filename>/etc/profile</filename> or
    153 <filename>.bash_profile</filename> files, but reads the
    154 <filename>.bashrc</filename> file instead. Create this latter file now:</para>
    155 
    156 <screen><userinput>cat &gt; ~/.bashrc &lt;&lt; "EOF"</userinput>
    157 set +h
    158 umask 022
    159 LFS=/mnt/lfs
    160 LC_ALL=POSIX
    161 PATH=/tools/bin:/bin:/usr/bin
    162 export LFS LC_ALL PATH
    163 <userinput>EOF</userinput></screen>
    164 
    165 <para>The <command>set +h</command> command turns off
    166 <command>bash</command>'s hash function. Normally hashing is a useful
    167 feature: <command>bash</command> uses a hash table to remember the
    168 full pathnames of executable files to avoid searching the PATH time and time
    169 again to find the same executable. However, we'd like the new tools to be
    170 used as soon as they are installed. By switching off the hash function, our
    171 "interactive" commands (<command>make</command>,
    172 <command>patch</command>, <command>sed</command>,
    173 <command>cp</command> and so forth) will always use
    174 the newest available version during the build process.</para>
    175 
    176 <para>Setting the user file-creation mask to 022 ensures that newly created
    177 files and directories are only writable for their owner, but readable and
    178 executable for anyone.</para>
    179 
    180 <para>The LFS variable should of course be set to the mount point you
    181 chose.</para>
    182 
    183 <para>The LC_ALL variable controls the localization of certain programs,
    184 making their messages follow the conventions of a specified country. If your
    185 host system uses a version of Glibc older than 2.2.4,
    186 having LC_ALL set to something other than "POSIX" or "C" during this chapter
    187 may cause trouble if you exit the chroot environment and wish to return later.
    188 By setting LC_ALL to "POSIX" (or "C", the two are equivalent) we ensure that
    189 everything will work as expected in the chroot environment.</para>
    190 
    191 <para>We prepend <filename>/tools/bin</filename> to the standard PATH so
    192 that, as we move along through this chapter, the tools we build will get used
    193 during the rest of the building process.</para>
    194 
    195 <para>Finally, to have our environment fully prepared for building the
    196 temporary tools, source the just-created profile:</para>
    197 
    198 <screen><userinput>source ~/.bash_profile</userinput></screen>
    199 
    200 </sect1>
    201 
    202 
    203 <sect1 id="prepare-aboutsbus">
    204 <title>About SBUs</title>
    205 <?dbhtml filename="aboutsbus.html" dir="chapter04"?>
    206 
    207 <para>Most people would like to know beforehand how long it approximately
    208 takes to compile and install each package. But "Linux from Scratch" is built
    209 on so many different systems, it is not possible to give actual times that are
    210 anywhere near accurate: the biggest package (Glibc) won't take more than
    211 twenty minutes on the fastest systems, but will take something like three days
    212 on the slowest -- no kidding. So instead of giving actual times, we've come up
    213 with the idea of using the <emphasis>Static Binutils Unit</emphasis>
    214 (abbreviated to <emphasis>SBU</emphasis>).</para>
    215 
    216 <para>It works like this: the first package you compile in this book is the
    217 statically linked Binutils in <xref linkend="chapter-temporary-tools"/>, and the time it
    218 takes to compile this package is what we call the "Static Binutils Unit" or
    219 "SBU". All other compile times will be expressed relative to this time.</para>
    220 
    221 <para>For example, the time it takes to build the static version of GCC is
    222 &gcc-time-tools-pass1;s. This means that if on your system it took 10 minutes
    223 to compile and install the static Binutils, then you know it will take
    224 approximately 45 minutes to build the static GCC. Fortunately, most build times
    225 are much shorter than the one of Binutils.</para>
    226 
    227 <para>Note that if the system compiler on your host is GCC-2 based, the SBUs
    228 listed may end up being somewhat understated. This is because the SBU is based
    229 on the very first package, compiled with the old GCC, while the rest of the
    230 system is compiled with the newer GCC-&gcc-version; which is known to be
    231 approximately 30% slower.</para>
    232 
    233 <para>Also note that SBUs don't work well for SMP-based machines. But if you're
    234 so lucky as to have multiple processors, chances are that your system is so fast
    235 that you won't mind.</para>
    236 
    237 <para>If you wish to see actual timings for specific machines, have a look at
    238 <ulink url="&lfs-root;~bdubbs/"/>.</para>
    239 
    240 </sect1>
    241 
    242 
    243 <sect1 id="prepare-abouttestsuites">
    244 <title>About the test suites</title>
    245 <?dbhtml filename="abouttestsuites.html" dir="chapter04"?>
    246 
    247 <para>Most packages provide a test suite. Running the test suite for a newly
    248 built package is generally a good idea, as it can provide a nice sanity check
    249 that everything compiled correctly. A test suite that passes its set of checks
    250 usually proves that the package is functioning as the developer intended. It
    251 does not, however, guarantee that the package is totally bug free.</para>
    252 
    253 <para>Some test suites are more important than others. For example, the test
    254 suites for the core toolchain packages -- GCC, Binutils, and Glibc -- are of
    255 the utmost importance due to their central role in a properly functioning
    256 system. But be warned, the test suites for GCC and Glibc can take a very long
    257 time to complete, especially on slower hardware.</para>
    258 
    259 <note><para>Experience has shown us that there is little to be gained from running
    260 the test suites in <xref linkend="chapter-temporary-tools"/>. There can be no
    261 escaping the fact that the host system always exerts some influence on the
    262 tests in that chapter, often causing weird and inexplicable failures. Not only
    263 that, the tools built in <xref linkend="chapter-temporary-tools"/> are
    264 temporary and eventually discarded. For the average reader of this book we
    265 recommend <emphasis>not</emphasis> to run the test suites in <xref
    266 linkend="chapter-temporary-tools"/>. The instructions for running those test
    267 suites are still provided for the benefit of testers and developers, but they
    268 are strictly optional for everyone else.</para></note>
    269 
    270 <para>A common problem when running the test suites for Binutils and GCC is
    271 running out of pseudo terminals (PTYs for short). The symptom is a very high
    272 number of failing tests. This can happen for several reasons, but the most
    273 likely cause is that the host system doesn't have the
    274 <emphasis>devpts</emphasis> file system set up correctly. We'll discuss this in
    275 more detail later on in <xref linkend="chapter-temporary-tools"/>.</para>
    276 
    277 <para>Sometimes package test suites will give false failures. You can
    278 consult the LFS Wiki at <ulink url="&wiki-root;"/> to verify that these
    279 failures are normal. This applies to all tests throughout the book.</para>
    280 
    281 </sect1>
    282 
     12<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="aboutlfs.xml"/>
     13<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="creatingtoolsdir.xml"/>
     14<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="addinguser.xml"/>
     15<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="settingenviron.xml"/>
     16<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="aboutsbus.xml"/>
     17<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="abouttestsuites.xml"/>
    28318
    28419</chapter>
Note: See TracChangeset for help on using the changeset viewer.