Changeset 155d6d1 for chapter04


Ignore:
Timestamp:
01/30/2005 10:36:17 AM (19 years ago)
Author:
Manuel Canales Esparcia <manuel@…>
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:
8bbebcc
Parents:
4642c89
Message:

Removed obsolete commented text, chapter04.

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

Location:
chapter04
Files:
6 edited

Legend:

Unmodified
Added
Removed

  • chapter04/aboutlfs.xml

    r4642c89 r155d6d1  
    1010<para>See testing</para>
    1111
    12 <!--
    13 <para>Throughout this book the environment variable LFS will be used several
    14 times. It is paramount that this variable is always defined. It should be set
    15 to the mount point you chose for your LFS partition. Check that your LFS
    16 variable is set up properly with:</para>
    17 
    18 <screen><userinput>echo $LFS</userinput></screen>
    19 
    20 <para>Make sure the output shows the path to your LFS partition's mount
    21 point, which is <filename class="directory">/mnt/lfs</filename> if you
    22 followed our example. If the output is wrong, you can always set the variable
    23 with:</para>
    24 
    25 <screen><userinput>export LFS=/mnt/lfs</userinput></screen>
    26 
    27 <para>Having this variable set means that if you are told to run a command like
    28 <command>mkdir $LFS/tools</command>, you can type it literally. Your shell
    29 will replace <quote>$LFS</quote> with <quote>/mnt/lfs</quote> (or whatever
    30 you set the variable to) when it processes the command line.</para>
    31 
    32 <para>Don't forget to check that <quote>$LFS</quote> is set whenever you leave and
    33 reenter the environment (as when doing a <quote>su</quote> to root or another user).
    34 </para>
    35 -->
    36 
    3712</sect1>

  • chapter04/aboutsbus.xml

    r4642c89 r155d6d1  
    1010<para>See testing</para>
    1111
    12 <!--
    13 <para>Most people would like to know beforehand approximately how long it
    14 takes to compile and install each package. But <quote>Linux from Scratch</quote> is built
    15 on so many different systems, it is not possible to give actual times that are
    16 anywhere near accurate: the biggest package (Glibc) won't take more than
    17 twenty minutes on the fastest systems, but will take something like three days
    18 on the slowest - no kidding. So instead of giving actual times, we've come up
    19 with the idea of using the <emphasis>Static Binutils Unit</emphasis>
    20 (abbreviated to <emphasis>SBU</emphasis>).</para>
    21 
    22 <para>It works like this: the first package you compile in this book is the
    23 statically linked Binutils in <xref linkend="chapter-temporary-tools"/>, and the time it
    24 takes to compile this package is what we call the <quote>Static Binutils
    25 Unit</quote> or <quote>SBU</quote>. All other compile times will be expressed
    26 relative to this time.</para>
    27 
    28 <para>For example, consider a particular package whose compilation time is 4.5
    29 SBUs. This means that if on your system it took 10 minutes to compile and
    30 install the static Binutils, then you know it will take
    31 <emphasis>approximately</emphasis> 45 minutes to build this package.
    32 Fortunately, most build times are much shorter than the one of Binutils.</para>
    33 
    34 <para>Note that if the system compiler on your host is GCC-2 based, the SBUs
    35 listed may end up being somewhat understated. This is because the SBU is based
    36 on the very first package, compiled with the old GCC, while the rest of the
    37 system is compiled with the newer GCC-&gcc-version; which is known to be
    38 approximately 30% slower.</para>
    39 
    40 <para>Also note that SBUs don't work well for SMP-based machines. But if you're
    41 so lucky as to have multiple processors, chances are that your system is so fast
    42 that you won't mind.</para>
    43 
    44 <para>If you wish to see actual timings for specific machines, have a look at
    45 <ulink url="&lfs-root;~bdubbs/"/>.</para>
    46 -->
    47 
    4812</sect1>

  • chapter04/abouttestsuites.xml

    r4642c89 r155d6d1  
    1010<para>See testing</para>
    1111
    12 <!--
    13 <para>Most packages provide a test suite. Running the test suite for a newly
    14 built package is generally a good idea, as it can provide a nice sanity check
    15 that everything compiled correctly. A test suite that passes its set of checks
    16 usually proves that the package is functioning as the developer intended. It
    17 does not, however, guarantee that the package is totally bug free.</para>
    18 
    19 <para>Some test suites are more important than others. For example, the test
    20 suites for the core toolchain packages - GCC, Binutils, and Glibc - are of
    21 the utmost importance due to their central role in a properly functioning
    22 system. But be warned, the test suites for GCC and Glibc can take a very long
    23 time to complete, especially on slower hardware.</para>
    24 
    25 <note><para>Experience has shown us that there is little to be gained from running
    26 the test suites in <xref linkend="chapter-temporary-tools"/>. There can be no
    27 escaping the fact that the host system always exerts some influence on the
    28 tests in that chapter, often causing weird and inexplicable failures. Not only
    29 that, the tools built in <xref linkend="chapter-temporary-tools"/> are
    30 temporary and eventually discarded. For the average reader of this book we
    31 recommend <emphasis>not</emphasis> to run the test suites in
    32 <xref linkend="chapter-temporary-tools"/>. The instructions for running those test
    33 suites are still provided for the benefit of testers and developers, but they
    34 are strictly optional for everyone else.</para></note>
    35 
    36 <para>A common problem when running the test suites for Binutils and GCC is
    37 running out of pseudo terminals (PTYs for short). The symptom is a very high
    38 number of failing tests. This can happen for several reasons, but the most
    39 likely cause is that the host system doesn't have the
    40 <emphasis>devpts</emphasis> file system set up correctly. We'll discuss this in
    41 more detail later on in <xref linkend="chapter-temporary-tools"/>.</para>
    42 
    43 <para>Sometimes package test suites will give false failures. You can
    44 consult the LFS Wiki at <ulink url="&wiki-root;"/> to verify that these
    45 failures are normal. This applies to all tests throughout the book.</para>
    46 -->
    47 
    4812</sect1>

  • chapter04/addinguser.xml

    r4642c89 r155d6d1  
    88<?dbhtml filename="addinguser.html"?>
    99
    10 <!--
    11 <para>When logged in as <emphasis>root</emphasis>, making a single mistake
    12 can damage or even wreck your system. Therefore we recommend that you
    13 build the packages in this chapter as an unprivileged user. You could
    14 of course use your own user name, but to make it easier to set up a clean
    15 work environment we'll create a new user <emphasis>lfs</emphasis> as a
    16 member of a new group (also named <emphasis>lfs</emphasis>) and
    17 use this one during the installation process. As <emphasis>root</emphasis>,
    18 issue the following commands to add the new user:</para>
    19 -->
     10<para>Issue the following commands to add the new user:</para>
    2011
    2112<screen><userinput>groupadd lfs
    2213useradd -s /bin/bash -g lfs -m -k /dev/null lfs</userinput></screen>
    2314
    24 <!--
    25 <para>The meaning of the switches:</para>
    26 
    27 <variablelist>
    28 <varlistentry>
    29 <term><parameter>-s /bin/bash</parameter></term>
    30 <listitem><para>This makes
    31 <command>bash</command> the default shell for user
    32 <emphasis>lfs</emphasis>.</para></listitem>
    33 </varlistentry>
    34 
    35 <varlistentry>
    36 <term><parameter>-g lfs</parameter></term>
    37 <listitem><para>This adds user <emphasis>lfs</emphasis> to group
    38 <emphasis>lfs</emphasis></para></listitem>
    39 </varlistentry>
    40 
    41 <varlistentry>
    42 <term><parameter>-m</parameter></term>
    43 <listitem><para>This creates a home
    44 directory for <emphasis>lfs</emphasis>.</para></listitem>
    45 </varlistentry>
    46 
    47 <varlistentry>
    48 <term><parameter>-k /dev/null</parameter></term>
    49 <listitem><para>This parameter
    50 prevents possible copying of files from a skeleton directory (default
    51 is <filename class="directory">/etc/skel</filename>) by changing the input location to
    52 the special null device.</para></listitem>
    53 </varlistentry>
    54 </variablelist>
    55 
    56 <para>If you want to be able to log in as <emphasis>lfs</emphasis>, then give
    57 <emphasis>lfs</emphasis> a password:</para>
    58 -->
    59 
    6015<screen><userinput>passwd lfs</userinput></screen>
    61 
    62 <!--
    63 <para>and grant <emphasis>lfs</emphasis> full access to
    64 <filename class="directory">$LFS/tools</filename> by making
    65 <emphasis>lfs</emphasis> the directory owner:</para>
    66 -->
    6716
    6817<screen><userinput>chown lfs $LFS/tools</userinput></screen>
    6918
    70 <!--
    71 <para>If you made a separate working directory as suggested, give user
    72 <emphasis>lfs</emphasis> ownership of this directory too:</para>
    73 -->
    74 
    7519<screen><userinput>chown lfs $LFS/sources</userinput></screen>
    76 
    77 <!--
    78 <para>Next, login as user <emphasis>lfs</emphasis>. This can be done via a
    79 virtual console, through a display manager, or with the following substitute
    80 user command:</para>
    81 -->
    8220
    8321<screen><userinput>su - lfs</userinput></screen>
    8422
    85 <!--
    86 <para>The <quote><parameter>-</parameter></quote> instructs <command>su</command> to
    87 start a <emphasis>login</emphasis> shell.</para>
    88 -->
    89 
    9023</sect1>

  • chapter04/creatingtoolsdir.xml

    r4642c89 r155d6d1  
    88<?dbhtml filename="creatingtoolsdir.html"?>
    99
    10 <!--
    11 <para>All programs compiled in <xref 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 programs compiled here are only
    14 temporary tools and won't be a part of the final LFS system and by keeping them
    15 in a separate directory, we can later easily throw them away. This also
    16 helps prevent them from ending up in your host's production directories
    17 (easy to do in <xref linkend="chapter-temporary-tools"/>), which could be a very bad thing.</para>
    18 
    19 <para>Later on you might wish to search through the binaries of your system to
    20 see what files they make use of or link against. To make this searching easier
    21 you may want to choose a unique name for the directory in which the temporary
    22 tools are stored. Instead of the simple <quote>tools</quote> you could use
    23 something like <quote>tools-for-lfs</quote>. However, you'll need to be careful
    24 to adjust all references to <quote>tools</quote> throughout the book -
    25 including those in any patches, notably the GCC Specs Patch.</para>
    26 
    27 <para>Create the required directory by running the following:</para>
    28 -->
    29 
    3010<screen><userinput>mkdir $LFS/tools</userinput></screen>
    31 
    32 <!--
    33 <para>The next step is to create a <filename>/tools</filename> symlink on
    34 your <emphasis>host</emphasis> system. It will point to the directory we just created on the LFS
    35 partition:</para>
    36 -->
    3711
    3812<screen><userinput>ln -s $LFS/tools /</userinput></screen>
    3913
    40 <!--
    41 <note><para>The above command is correct. The <command>ln</command> command
    42 has a few syntactic variations, so be sure to check the info page before
    43 reporting what you may think is an error.</para></note>
    44 
    45 <para>The created symlink enables us to compile our toolchain so that it always
    46 refers to <filename class="directory">/tools</filename>, meaning that the compiler, assembler
    47 and linker will work both in this chapter (when we are still using some tools
    48 from the host) <emphasis>and</emphasis> in the next (when we are <quote>chrooted</quote> to
    49 the LFS partition).</para>
    50 -->
    51 
    5214</sect1>

  • chapter04/settingenviron.xml

    r4642c89 r155d6d1  
    88<?dbhtml filename="settingenvironment.html"?>
    99
    10 <!--
    11 <para>We're going to set up a good working environment by creating two new
    12 startup files for the <command>bash</command> shell. While logged in as
    13 user <emphasis>lfs</emphasis>, issue the following command to create a new
    14 <filename>.bash_profile</filename>:</para>
    15 -->
    16 
    1710<screen><userinput>cat &gt; ~/.bash_profile &lt;&lt; "EOF"
    1811exec env -i HOME=$HOME TERM=$TERM PS1='\u:\w\$ ' /bin/bash
    1912EOF</userinput></screen>
    20 
    21 <!--
    22 <para>Normally, when you log on as user <emphasis>lfs</emphasis>,
    23 the initial shell is a <emphasis>login</emphasis> shell which reads the
    24 <filename>/etc/profile</filename> of your host (probably containing some
    25 settings of environment variables) and then <filename>.bash_profile</filename>.
    26 The <command>exec env -i ... /bin/bash</command> command in the latter file
    27 replaces the running shell with a new one with a completely empty environment,
    28 except for the HOME, TERM and PS1 variables. This ensures that no unwanted and
    29 potentially hazardous environment variables from the host system leak into our
    30 build environment. The technique used here is a little strange, but it achieves
    31 the goal of enforcing a clean environment.</para>
    32 
    33 <para>The new instance of the shell is a <emphasis>non-login</emphasis> shell,
    34 which doesn't read the <filename>/etc/profile</filename> or
    35 <filename>.bash_profile</filename> files, but reads the
    36 <filename>.bashrc</filename> file instead. Create this latter file now:</para>
    37 -->
    3813
    3914<screen><userinput>cat &gt; ~/.bashrc &lt;&lt; "EOF"
    … …  
    4621EOF</userinput></screen>
    4722
    48 <!--
    49 <para>The <command>set +h</command> command turns off
    50 <command>bash</command>'s hash function. Normally hashing is a useful
    51 feature: <command>bash</command> uses a hash table to remember the
    52 full pathnames of executable files to avoid searching the PATH time and time
    53 again to find the same executable. However, we'd like the new tools to be
    54 used as soon as they are installed. By switching off the hash function, our
    55 <quote>interactive</quote> commands (<command>make</command>,
    56 <command>patch</command>, <command>sed</command>,
    57 <command>cp</command> and so forth) will always use
    58 the newest available version during the build process.</para>
    59 
    60 <para>Setting the user file-creation mask to 022 ensures that newly created
    61 files and directories are only writable for their owner, but readable and
    62 executable for anyone.</para>
    63 
    64 <para>The LFS variable should of course be set to the mount point you
    65 chose.</para>
    66 
    67 <para>The LC_ALL variable controls the localization of certain programs,
    68 making their messages follow the conventions of a specified country. If your
    69 host system uses a version of Glibc older than 2.2.4,
    70 having LC_ALL set to something other than <quote>POSIX</quote> or
    71 <quote>C</quote> during this chapter may cause trouble if you exit the chroot
    72 environment and wish to return later.  By setting LC_ALL to <quote>POSIX</quote>
    73 (or <quote>C</quote>, the two are equivalent) we ensure that
    74 everything will work as expected in the chroot environment.</para>
    75 
    76 <para>We prepend <filename class="directory">/tools/bin</filename> to the standard PATH so
    77 that, as we move along through this chapter, the tools we build will get used
    78 during the rest of the building process.</para>
    79 
    80 <para>Finally, to have our environment fully prepared for building the
    81 temporary tools, source the just-created profile:</para>
    82 -->
    83 
    8423<screen><userinput>source ~/.bash_profile</userinput></screen>
    8524
Note: See TracChangeset for help on using the changeset viewer.