Changeset 1668d8e


Ignore:
Timestamp:
10/11/2003 10:51:08 AM (21 years ago)
Author:
Alex Gronenwoud <alex@…>
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_0, 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:
313e0960
Parents:
1f0f472
Message:

Adding some markup, and other brush-ups.

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

Files:
7 edited

Legend:

Unmodified
Added
Removed

  • chapter01/changelog.xml

    r1f0f472 r1668d8e  
    105105&lt;screen&gt; (and the matching closing tags).</para></listitem>
    106106
     107<listitem><para>October 9th, 2003 [alex]: Chapter 6 - Basic Networking: Moved
     108one half to the Lfs-Utils section, the other half to Perl.</para></listitem>
     109 
    107110<listitem><para>October 8th, 2003 [alex]: Chapter 8 - Making bootable: Adapted
    108111the style of the screens, and reworded some paragraphs.</para></listitem>
    … …  
    148151MD5 passwords. Closes Bug 600.</para></listitem>
    149152
    150 <listitem><para>September 27th, 2003 [greg]: Chapter 5 - Expect: Tweak install
    151 so that redundant scripts are not installed. Chapter 6 - Creating essential
    152 symlinks: Remove redundant links. Chapter 6 - man: Remove PATH, closes
    153 Bug 574.</para></listitem>
    154 
    155 <listitem><para>September 27th, 2003 [greg]: Add Tcl, Expect and DejaGnu items
    156 to Appendix A. Closes Bug 661.</para></listitem>
     153<listitem><para>September 27th, 2003 [greg]: Chapter 5 - Expect: Tweaked
     154install so that redundant scripts are not installed. Chapter 6 - Creating
     155essential symlinks: Removed redundant links. Chapter 6 - man: Removed PATH,
     156closes Bug 574.</para></listitem>
     157
     158<listitem><para>September 27th, 2003 [greg]: Added Tcl, Expect and DejaGnu
     159items to Appendix A. Closes Bug 661.</para></listitem>
    157160
    158161<listitem><para>September 26th, 2003 [jeremy]: Added new workaround for the
    … …  
    168171file: Made mounting devpts the default.</para></listitem>
    169172
    170 <listitem><para>September 22nd, 2003 [jeremy]: Added net-tools patch to fix
     173<listitem><para>September 22nd, 2003 [jeremy]: Added Net-tools patch to fix
    171174mii-tool compilation.</para></listitem>
    172175
    … …  
    188191mount devpts if you exit and re-enter chroot.</para></listitem>
    189192
    190 <listitem><para>September 22nd, 2003 [jeremy]: removed make check from patch
    191 and diffutils, since these tests perform no actions.</para></listitem>
     193<listitem><para>September 22nd, 2003 [jeremy]: Removed make check from Patch
     194and Diffutils, since these tests perform no actions.</para></listitem>
    192195
    193196<listitem><para>September 22nd, 2003 [greg]: Chapter 5 - Setting up the
    … …  
    205208acknowledgements page.</para></listitem>
    206209
    207 <listitem><para>September 18th, 2003 [jeremy]: Chapter 5 - GCC Pass 2 -
    208 added some extra comments regarding the 3 tarballs to unpack.</para></listitem>
     210<listitem><para>September 18th, 2003 [jeremy]: Chapter 5 - GCC Pass 2: Added
     211some extra comments regarding the 3 tarballs to unpack.</para></listitem>
    209212
    210213<listitem><para>September 17th, 2003 [greg]: Chapter 6 - GCC-2.95.3: Added
    … …  
    216219<listitem><para>September 17th, 2003 [jeremy]: Upgraded File to 4.04.</para></listitem>
    217220
    218 <listitem><para>September 17th, 2003 [jeremy]: Chapter 6 - changed 2 of the
     221<listitem><para>September 17th, 2003 [jeremy]: Chapter 6 - Changed 2 of the
    219222occurrences of exec bash --login to include the +h directive. </para></listitem>
    220223

  • chapter05/binutils-pass2-inst.xml

    r1f0f472 r1668d8e  
    33<sect2>
    44<title>Re-installation of Binutils</title>
    5 
    6 <note><para>It's worth pointing out that the Binutils test suite we run in this
    7 section is considered not as important as the one we run in Chapter 6.</para>
    8 </note>
    95
    106<para>Create a separate build directory again:</para>

  • chapter05/chapter05.xml

    r1f0f472 r1668d8e  
    6262<screen><userinput>rm -rf /tools/{,share/}{doc,info,man}</userinput></screen>
    6363
    64 <para>You will now need to have at least 700 MB of free space on your LFS
    65 filesystem to be able to build and install Glibc in the next phase.</para>
     64<para>You will now need to have at least 800 MB of free space on your LFS
     65filesystem to be able to build and install Glibc in the next phase. If you can
     66build and install Glibc, you can build and install the rest too.</para>
    6667
    6768</sect1>

  • chapter05/gcc-pass2-inst.xml

    r1f0f472 r1668d8e  
    108108version of the GCC sources we used earlier.</para>
    109109
     110<note><para>It's worth pointing out that running the GCC test suite here
     111is considered not as important running it in Chapter 6.</para></note>
     112
    110113<para>Test the results:</para>
    111114
    … …  
    156159we performed earlier in the chapter. Refer back to
    157160<xref linkend="ch05-locking-glibc"/> and repeat the check. If the results are
    158 wrong then most likely, you forgot to apply the above mentioned GCC Specs
     161wrong, then most likely you forgot to apply the above mentioned GCC Specs
    159162patch.</para></note>
    160163

  • chapter05/glibc-inst.xml

    r1f0f472 r1668d8e  
    1010
    1111<note><para>We are going to run the test suite for Glibc in this chapter.
    12 However, it's worth pointing out that the Glibc test suite we run in this
    13 section is considered not as important as the one we run in Chapter 6.</para></note>
     12However, it's worth pointing out that running the Glibc test suite here
     13is considered not as important as running it in Chapter 6.</para></note>
    1414
    1515<para>This package is known to behave badly when you have changed its
    … …  
    9090
    9191<para>The Glibc test suite is highly dependent on certain functions of your host
    92 system, in particular the kernel. Additionally, here in Chapter 5, some tests
     92system, in particular the kernel. Additionally, here in Chapter 5 some tests
    9393can be adversely affected by existing tools or environmental issues on the host
    9494system. Of course, these won't be a problem when we run the Glibc test suite
    … …  
    9999
    100100<itemizedlist>
    101 <listitem><para>The math tests sometimes fail when running on systems where the
    102 CPU is not a relatively new genuine Intel or genuine AMD. Certain optimization
    103 settings are also known to be a factor here.</para></listitem>
     101<listitem><para>The <emphasis>math</emphasis> tests sometimes fail when running
     102on systems where the CPU is not a relatively new genuine Intel or authentic AMD.
     103Certain optimization settings are also known to be a factor here.</para></listitem>
    104104
    105 <listitem><para>The gettext test sometimes fails due to host system issues. The
    106 exact reasons are not yet clear.</para></listitem>
     105<listitem><para>The <emphasis>gettext</emphasis> test sometimes fails due to
     106host system issues. The exact reasons are not yet clear.</para></listitem>
    107107
    108 <listitem><para>The atime test sometimes fails when the LFS partition is mounted
    109 with the noatime option or due to other file system quirks.</para></listitem>
     108<listitem><para>The <emphasis>atime</emphasis> test sometimes fails when the
     109LFS partition is mounted with the <emphasis>noatime</emphasis> option, or due
     110to other file system quirks.</para></listitem>
    110111
    111 <listitem><para>In general, when running on slower hardware, some tests might
     112<listitem><para>The <emphasis>shm</emphasis> test might fail when the host
     113system is running the devfs file system but doesn't have the tmpfs file system
     114mounted at <filename>/dev/shm</filename> due to lack of support for tmpfs in
     115the kernel.</para></listitem>
     116
     117<listitem><para>When running on older and slower hardware, some tests might
    112118fail due to test timeouts being exceeded.</para></listitem>
    113 
    114 <listitem><para>The shm test might fail in the circumstances of the host system
    115 running the devfs file system but not having the tmpfs file system mounted at
    116 /dev/shm due to lack of support for tmpfs in the kernel.</para></listitem>
    117119</itemizedlist>
    118120
    … …  
    120122in Chapter 5. The Glibc in Chapter 6 is the one we'll ultimately end up using so
    121123that is the one we would really like to see pass. But please keep in mind, even
    122 in Chapter 6 some failures could still occur, the math tests for example. When
    123 experiencing a failure, note the failure then continue on by reissuing the
    124 <userinput>make check</userinput>. The test suite should pick up where it left
    125 off and continue on. You can circumvent this stop-start sequence by issuing a
    126 <userinput>make -k check</userinput>. But If you do that, be sure to log the
    127 output so that you can later on peruse the log file and examine the total number
    128 of failures.</para>
     124in Chapter 6 some failures could still occur -- the <emphasis>math</emphasis>
     125tests for example. When experiencing a failure, make a note of it, then
     126continue by reissuing the <userinput>make check</userinput>. The test suite
     127should pick up where it left off and continue on. You can circumvent this
     128stop-start sequence by issuing a <userinput>make -k check</userinput>. But if
     129you do that, be sure to log the output so that you can later peruse the log
     130file and examine the total number of failures.</para>
    129131
    130132<para>Now install the package:</para>
    … …  
    135137communicate. These conventions range from very simple ones, such as the format
    136138for representing dates and times, to very complex ones, such as the language
    137 spoken. This "internationalization" works by means of locales. We'll install the
    138 Glibc locales now:</para>
     139spoken. The "internationalization" of GNU programs works by means of
     140<emphasis>locales</emphasis>. We'll install the Glibc locales now:</para>
    139141
    140142<screen><userinput>make localedata/install-locales</userinput></screen>
    … …  
    144146<userinput>localedef</userinput> command. Information on this can be
    145147found in the <filename>INSTALL</filename> file in the
    146 <filename>glibc-&glibc-version;</filename> source. However, there are a
    147 number of locales that are essential for the tests of future packages
    148 to pass correctly, in particular, the libstdc++ tests from GCC.  The following
    149 instructions, instead of the install-locales command above, will install
     148<filename>glibc-&glibc-version;</filename> source. However, there are a number
     149of locales that are essential for the tests of future packages to pass, in
     150particular, the <emphasis>libstdc++</emphasis> tests from GCC.  The following
     151instructions, instead of the install-locales target above, will install
    150152the minimum set of locales necessary for the tests to run successfully:</para>
    151153

  • chapter05/toolchaintechnotes.xml

    r1f0f472 r1668d8e  
    1414build a self-contained and self-hosted toolchain. It should be noted that the
    1515build process has been designed in such a way so as to minimize the risks for
    16 new readers and also provide maximum educational value at the same time. In
    17 other words, more advanced techniques could be used to achieve the same
    18 goals.</para>
     16new readers and provide maximum educational value at the same time. In other
     17words, more advanced techniques could be used to build the system.</para>
    1918
    2019<important>
    … …  
    5756choose.</para></listitem>
    5857
    59 <listitem><para>Careful manipulation of GCC's <emphasis>specs</emphasis> file to
    60 tell GCC which target dynamic linker will be used.</para></listitem>
     58<listitem><para>Careful manipulation of <userinput>gcc</userinput>'s
     59<emphasis>specs</emphasis> file to tell the compiler which target dynamic
     60linker will be used.</para></listitem>
    6161</itemizedlist>
    6262
    6363<para>Binutils is installed first because both GCC and Glibc perform various
    6464feature tests on the assembler and linker during their respective runs of
    65 <filename>./configure</filename> to determine which software features to enable
     65<userinput>./configure</userinput> to determine which software features to enable
    6666or disable. This is more important than one might first realize. An incorrectly
    6767configured GCC or Glibc can result in a subtly broken toolchain where the impact
    68 of such breakage might not show up until near the end of a build of a whole
     68of such breakage might not show up until near the end of the build of a whole
    6969distribution. Thankfully, a test suite failure will usually alert us before too
    70 much harm is done.</para>
     70much time is wasted.</para>
    7171
    7272<para>Binutils installs its assembler and linker into two locations,
    7373<filename class="directory">/tools/bin</filename> and
    7474<filename class="directory">/tools/$TARGET_TRIPLET/bin</filename>. In reality,
    75 the tools in one location are hard linked to the other. An important facet of ld
    76 is its library search order. Detailed information can be obtained from ld by
    77 passing it the <emphasis>--verbose</emphasis> flag. For example:
    78 <userinput>`ld --verbose | grep SEARCH`</userinput> will show you the current
    79 search paths and order. You can see what files are actually linked by ld by
    80 compiling a dummy program and passing the --verbose switch. For example:
     75the tools in one location are hard linked to the other. An important facet of
     76the linker is its library search order. Detailed information can be obtained
     77from <userinput>ld</userinput> by passing it the <emphasis>--verbose</emphasis>
     78flag. For example: <userinput>`ld --verbose | grep SEARCH`</userinput> will
     79show you the current search paths and their order. You can see what files are
     80actually linked by <userinput>ld</userinput> by compiling a dummy program and
     81passing the <emphasis>--verbose</emphasis> switch. For example:
    8182<userinput>`gcc dummy.c -Wl,--verbose 2>&amp;1 | grep succeeded`</userinput>
    8283will show you all the files successfully opened during the link.</para>
    8384
    8485<para>The next package installed is GCC and during its run of
    85 <filename>./configure</filename> you'll see, for example:</para>
     86<userinput>./configure</userinput> you'll see, for example:</para>
    8687
    8788<blockquote><screen>checking what assembler to use... /tools/i686-pc-linux-gnu/bin/as
    … …  
    9091<para>This is important for the reasons mentioned above. It also demonstrates
    9192that GCC's configure script does not search the $PATH directories to find which
    92 tools to use. However, during the actual operation of GCC itself, the same
    93 search paths are not necessarily used. You can find out which standard linker
    94 GCC will use by running: <userinput>`gcc -print-prog-name=ld`</userinput>.
    95 Detailed information can be obtained from GCC by passing it the
    96 <emphasis>-v</emphasis> flag while compiling a dummy program. For example:
    97 <userinput>`gcc -v dummy.c`</userinput> will show you detailed information about
    98 the preprocessor, compilation and assembly stages, including GCC's include
    99 search paths and order.</para>
     93tools to use. However, during the actual operation of <userinput>gcc</userinput>
     94itself, the same search paths are not necessarily used. You can find out which
     95standard linker <userinput>gcc</userinput> will use by running:
     96<userinput>`gcc -print-prog-name=ld`</userinput>.
     97Detailed information can be obtained from <userinput>gcc</userinput> by passing
     98it the <emphasis>-v</emphasis> flag while compiling a dummy program. For
     99example: <userinput>`gcc -v dummy.c`</userinput> will show you detailed
     100information about the preprocessor, compilation and assembly stages, including
     101<userinput>gcc</userinput>'s include search paths and their order.</para>
    100102 
    101103<para>The next package installed is Glibc. The most important considerations for
    102104building Glibc are the compiler, binary tools and kernel headers. The compiler
    103 is generally no problem as it will always use the GCC found in a $PATH
    104 directory. The binary tools and kernel headers can be a little more troublesome.
    105 Therefore we take no risks and we use the available configure switches to
    106 enforce the correct selections. After the run of
    107 <filename>./configure</filename> you can check the contents of the
     105is generally no problem as Glibc will always use the <userinput>gcc</userinput>
     106found in a $PATH directory. The binary tools and kernel headers can be a little
     107more troublesome. Therefore we take no risks and use the available configure
     108switches to enforce the correct selections. After the run of
     109<userinput>./configure</userinput> you can check the contents of the
    108110<filename>config.make</filename> file in the
    109111<filename class="directory">glibc-build</filename> directory for all the
    110112important details. You'll note some interesting items like the use of
    111113<userinput>CC="gcc -B/tools/bin/"</userinput> to control which binary tools are
    112 used and also the use of the <emphasis>-nostdinc</emphasis> and
    113 <emphasis>-isystem</emphasis> flags to control the GCC include search path.
    114 These items help to highlight an important aspect of the Glibc package: it is
    115 very self sufficient in terms of its build machinery and generally does not rely
    116 on toolchain defaults.</para>
     114used, and also the use of the <emphasis>-nostdinc</emphasis> and
     115<emphasis>-isystem</emphasis> flags to control the compiler's include search
     116path. These items help to highlight an important aspect of the Glibc package:
     117it is very self-sufficient in terms of its build machinery and generally does
     118not rely on toolchain defaults.</para>
    117119
    118120<para>After the Glibc installation, we make some adjustments to ensure that
    119 searching and linking take place only within our /tools prefix. We install an
    120 adjusted ld, which has a hard-wired search path limited to
    121 <filename class="directory">/tools/lib</filename>. Then we amend GCC's specs
    122 file to point to our new dynamic linker in
    123 <filename class="directory">/tools/lib</filename>. This last step is
     121searching and linking take place only within our <filename>/tools</filename>
     122prefix. We install an adjusted <userinput>ld</userinput>, which has a hard-wired
     123search path limited to <filename class="directory">/tools/lib</filename>. Then
     124we amend <userinput>gcc</userinput>'s specs file to point to our new dynamic
     125linker in <filename class="directory">/tools/lib</filename>. This last step is
    124126<emphasis>vital</emphasis> to the whole process. As mentioned above, a
    125127hard-wired path to a dynamic linker is embedded into every ELF shared
    126128executable. You can inspect this by running:
    127129<userinput>`readelf -l &lt;name of binary&gt; | grep interpreter`</userinput>.
    128 By amending the GCC specs file, we are ensuring that every program compiled from
    129 here through the end of Chapter 5 will use our new dynamic linker in
    130 <filename class="directory">/tools/lib</filename>.</para>
     130By amending <userinput>gcc</userinput>'s specs file, we are ensuring that every
     131program compiled from here through the end of Chapter 5 will use our new
     132dynamic linker in <filename class="directory">/tools/lib</filename>.</para>
    131133
    132134<para>The need to use the new dynamic linker is also the reason why we apply the
    133 specs patch for the second pass of GCC. Failure to do so will result in the GCC
    134 programs themselves having the dynamic linker from the host system's
     135Specs patch for the second pass of GCC. Failure to do so will result in the GCC
     136programs themselves having the name of the dynamic linker from the host system's
    135137<filename class="directory">/lib</filename> directory embedded into them, which
    136 would defeat our goal of getting away from the host system.</para>
     138would defeat our goal of getting away from the host.</para>
    137139
    138140<para>During the second pass of Binutils, we are able to utilize the
    139 <userinput>--with-lib-path</userinput> configure switch to control ld's library
    140 search path. From this point onwards, the core toolchain is self-contained and
    141 self-hosted. The remainder of the Chapter 5 packages all build against the new
    142 Glibc in <filename class="directory">/tools</filename> and all is well.</para>
     141<emphasis>--with-lib-path</emphasis> configure switch to control
     142<userinput>ld</userinput>'s library search path. From this point onwards, the
     143core toolchain is self-contained and self-hosted. The remainder of the
     144Chapter 5 packages all build against the new Glibc in
     145<filename class="directory">/tools</filename> and all is well.</para>
    143146
    144147<para>Upon entering the chroot environment in Chapter 6, the first major package
    145 we install is Glibc, due to its self sufficient nature that we mentioned above.
     148we install is Glibc, due to its self-sufficient nature that we mentioned above.
    146149Once this Glibc is installed into <filename class="directory">/usr</filename>,
    147150we perform a quick changeover of the toolchain defaults, then proceed for real
    … …  
    164167resulting in a rather bulky program. When a program is dynamically linked, what
    165168is included is a reference to the dynamic linker, the name of the library, and
    166 the name of the function, resulting in a much smaller executable. A third way is
    167 to use the programming interface of the dynamic linker. See the
    168 <emphasis>dlopen</emphasis> man page for more information.</para>
     169the name of the function, resulting in a much smaller executable. (A third way
     170is to use the programming interface of the dynamic linker. See the
     171<emphasis>dlopen</emphasis> man page for more information.)</para>
    169172
    170173<para>Dynamic linking is the default on Linux and has three major advantages

  • chapter06/gcc-inst.xml

    r1f0f472 r1668d8e  
    7171
    7272<note><para>At this point it is strongly recommended to repeat the sanity check
    73 we performed earlier in the chapter. Refer back to
     73we performed in the previous chapter. Refer back to
    7474<xref linkend="ch06-adjustingtoolchain"/> and repeat the check. If the results
    75 are wrong then most likely, you erroneously applied the GCC Specs patch from
     75are wrong, then most likely you erroneously applied the GCC Specs patch from
    7676Chapter 5.</para></note>
    7777
Note: See TracChangeset for help on using the changeset viewer.