Changeset 9974e9b


Ignore:
Timestamp:
10/31/2022 06:58:31 AM (18 months ago)
Author:
Xi Ruoyao <xry111@…>
Branches:
xry111/arm64, xry111/arm64-12.0
Children:
6586901
Parents:
ad85e5b (diff), 61f8251 (diff)
Note: this is a merge changeset, the changes displayed below correspond to the merge itself.
Use the (diff) links above to see all the changes relative to each parent.
Message:

Merge remote-tracking branch 'origin/trunk' into xry111/arm64

Files:
10 edited

Legend:

Unmodified
Added
Removed

  • appendices/dependencies.xml

    rad85e5b r9974e9b  
    29992999        <seglistitem>
    30003000          <seg>Bash, Binutils, Coreutils, Diffutils, Eudev, Findutils, Gawk,
    3001           GCC, Gettext, Glibc, Grep, Libcap, Make, Ncurses, Sed, and Zlib</seg>
     3001          GCC, Gettext, Glibc, Grep, Make, Ncurses, Sed, and Zlib</seg>
    30023002        </seglistitem>
    30033003      </segmentedlist>
    … …  
    30063006        <segtitle>&runtime;</segtitle>
    30073007        <seglistitem>
    3008           <seg>Glibc, Libcap, Ncurses, Readline, and Zlib</seg>
     3008          <seg>Glibc, Ncurses, Readline, and Zlib</seg>
    30093009        </seglistitem>
    30103010      </segmentedlist>
    … …  
    30283028        <seglistitem>
    30293029          <seg>
     3030            <ulink
     3031              url="https://people.redhat.com/sgrubb/libcap-ng/">Libcap-NG</ulink>,
    30303032            <ulink
    30313033              url="&blfs-book;postlfs/linux-pam.html">Linux-PAM</ulink>

  • chapter01/askforhelp.xml

    rad85e5b r9974e9b  
    5151      </listitem>
    5252      <listitem>
    53         <para>The exact error message, or a clear decription of the problem</para>
     53        <para>The exact error message, or a clear description of the problem</para>
    5454      </listitem>
    5555      <listitem>

  • chapter04/addinguser.xml

    rad85e5b r9974e9b  
    6363      <term><parameter>lfs</parameter></term>
    6464      <listitem>
    65         <para>This is the actual name for the created user.</para>
     65        <para>This is the name of the new user.</para>
    6666      </listitem>
    6767    </varlistentry>
    … …  
    7272  non-&root; user (as opposed to switching to user &lfs-user;
    7373  when logged in as &root;, which does not require the &lfs-user; user to
    74   have a password), you need to set a password of &lfs-user;.  Issue the
     74  have a password), you need to set a password for &lfs-user;.  Issue the
    7575  following command as the &root; user to set the password:</para>
    7676

  • chapter04/settingenviron.xml

    rad85e5b r9974e9b  
    2020EOF</userinput></screen>
    2121
    22   <para>When logged on as user <systemitem class="username">lfs</systemitem>
    23   or switched to the &lfs-user; user using a <command>su</command> command
    24   with <quote><parameter>-</parameter></quote> option,
     22  <para>When logged on as user <systemitem class="username">lfs</systemitem>,
     23  or when switched to the &lfs-user; user using an <command>su</command> command
     24  with the <quote><parameter>-</parameter></quote> option,
    2525  the initial shell is a <emphasis>login</emphasis> shell which reads
    2626  the <filename>/etc/profile</filename> of the host (probably containing some
    … …  
    3131  <envar>TERM</envar>, and <envar>PS1</envar> variables. This ensures that no
    3232  unwanted and potentially hazardous environment variables from the host system
    33   leak into the build environment. The technique used here achieves the goal of
    34   ensuring a clean environment.</para>
     33  leak into the build environment.</para>
    3534
    3635  <para>The new instance of the shell is a <emphasis>non-login</emphasis>
    … …  
    101100  Setting <envar>LC_ALL</envar> to <quote>POSIX</quote> or <quote>C</quote>
    102101  (the two are equivalent) ensures that everything will work as expected in
    103   the chroot environment.</para>
     102  the cross-compilation environment.</para>
    104103      </listitem>
    105104    </varlistentry>
    … …  
    109108      <listitem>
    110109  <para>The <envar>LFS_TGT</envar> variable sets a non-default, but compatible machine
    111   description for use when building our cross compiler and linker and when cross
    112   compiling our temporary toolchain. More information is contained in
     110  description for use when building our cross-compiler and linker and when
     111  cross-compiling our temporary toolchain. More information is provided by
    113112  <xref linkend="ch-tools-toolchaintechnotes" role=""/>.</para>
    114113      </listitem>
    … …  
    133132      <listitem>
    134133  <para>If <filename class="directory">/bin</filename> is not a symbolic
    135   link, then it has to be added to the <envar>PATH</envar> variable.</para>
     134  link, it must be added to the <envar>PATH</envar> variable.</para>
    136135      </listitem>
    137136    </varlistentry>
    … …  
    164163      <term><parameter>export ...</parameter></term>
    165164      <listitem>
    166         <para>While the above commands have set some variables, in order
     165        <para>While the preceding commands have set some variables, in order
    167166        to make them visible within any sub-shells, we export them.</para>
    168167      </listitem>
    … …  
    173172  <important>
    174173
    175      <para>Several commercial distributions add a non-documented instantiation
     174     <para>Several commercial distributions add an undocumented instantiation
    176175     of <filename>/etc/bash.bashrc</filename> to the initialization of
    177176     <command>bash</command>. This file has the potential to modify the
    … …  
    186185     <screen role="nodump"><userinput>[ ! -e /etc/bash.bashrc ] || mv -v /etc/bash.bashrc /etc/bash.bashrc.NOUSE</userinput></screen>
    187186
    188      <para>After use of the <systemitem class="username">lfs</systemitem>
    189      user is finished at the beginning of <xref
    190      linkend="chapter-chroot-temporary-tools"/>, you can restore
     187     <para>When the <systemitem class="username">lfs</systemitem>
     188     user is no longer needed (at the beginning of <xref
     189     linkend="chapter-chroot-temporary-tools"/>), you may safely restore
    191190     <filename>/etc/bash.bashrc</filename> (if desired).</para>
    192191
    … …  
    197196  </important>
    198197
    199   <para>Finally, to have the environment fully prepared for building the
     198  <para>Finally, to ensure the environment is fully prepared for building the
    200199  temporary tools, force the <command>bash</command> shell to read
    201200  the new user profile:</para>

  • chapter05/binutils-pass1.xml

    rad85e5b r9974e9b  
    8585        <listitem>
    8686          <para>This tells the configure script to prepare to install the
    87           binutils programs in the <filename
     87          Binutils programs in the <filename
    8888          class="directory">$LFS/tools</filename> directory.</para>
    8989        </listitem>

  • chapter05/gcc-pass1.xml

    rad85e5b r9974e9b  
    5151
    5252    <note><para>There are frequent misunderstandings about this chapter.  The
    53     procedures are the same as every other chapter as explained earlier (<xref
    54     linkend='buildinstr'/>).  First extract the gcc tarball from the sources
    55     directory and then change to the directory created.  Only then should you
     53    procedures are the same as every other chapter, as explained earlier (<xref
     54    linkend='buildinstr'/>).  First, extract the gcc-&gcc-version; tarball from the sources
     55    directory, and then change to the directory created.  Only then should you
    5656    proceed with the instructions below.</para></note>
    5757
    … …  
    104104        <term><parameter>--with-glibc-version=&glibc-version;</parameter></term>
    105105        <listitem>
    106           <para>This option specifies the version of glibc which will be
     106          <para>This option specifies the version of Glibc which will be
    107107          used on the target. It is not relevant to the libc of the host
    108           distro because everything compiled by pass1 gcc will run in the
     108          distro because everything compiled by pass1 GCC will run in the
    109109          chroot environment, which is isolated from libc of the host
    110110          distro.</para>
    … …  
    149149        <listitem>
    150150          <para>This switch forces GCC to link its internal libraries
    151           statically. We need this because the shared libraries require glibc,
     151          statically. We need this because the shared libraries require Glibc,
    152152          which is not yet installed on the target system.</para>
    153153        </listitem>
    … …  
    200200    does not exist, so the internal header that has just been installed is a
    201201    partial, self-contained file and does not include the extended features of
    202     the system header. This is adequate for building glibc, but the full
     202    the system header. This is adequate for building Glibc, but the full
    203203    internal header will be needed later.  Create a full version of the internal
    204204    header using a command that is identical to what the GCC build system does

  • chapter05/glibc.xml

    rad85e5b r9974e9b  
    4444    <title>Installation of Glibc</title>
    4545
    46     <para>Some of the Glibc programs use the non-FHS compliant
     46    <para>Some of the Glibc programs use the non-FHS-compliant
    4747    <filename class="directory">/var/db</filename> directory to store their
    4848    runtime data. Apply the following patch to make such programs store their
    … …  
    108108        <listitem>
    109109          <para>This ensures that the library is installed in /usr/lib instead
    110           of the default /lib64 on 64 bit machines.</para>
     110          of the default /lib64 on 64-bit machines.</para>
    111111        </listitem>
    112112      </varlistentry>
    … …  
    126126    <para>The missing or incompatible <command>msgfmt</command> program is
    127127    generally harmless. This <command>msgfmt</command> program is part of the
    128     Gettext package which the host distribution should provide.</para>
     128    Gettext package, which the host distribution should provide.</para>
    129129
    130130    <note><para>There have been reports that this package may fail when
    131     building as a "parallel make".  If this occurs, rerun the make command
    132     with a "-j1" option.</para></note>
     131    building as a "parallel make".  If that occurs, rerun the make command
     132    with the "-j1" option.</para></note>
    133133
    134134    <para>Compile the package:</para>
    … …  
    141141    recommendations, you are building as
    142142    <systemitem class="username">root</systemitem>, the next command will
    143     install the newly built glibc to your host system, which most likely
    144     will render it unusable. So double check that the environment is
    145     correctly set, before running the following command.</para></warning>
     143    install the newly built Glibc to your host system, which will almost
     144    certainly render it unusable. So double-check that the environment is
     145    correctly set, and that you are not &root;, before running the following command.</para></warning>
    146146
    147147<screen><userinput remap="install">make DESTDIR=$LFS install</userinput></screen>
    … …  
    157157          installed. If it is not set, it defaults to the root (<filename
    158158          class="directory">/</filename>) directory. Here we specify that
    159           the package be installed in <filename class="directory">$LFS
    160           </filename>, which will become the root after <xref linkend=
     159          the package is installed in <filename class="directory">$LFS
     160          </filename>, which will become the root directory in <xref linkend=
    161161          "ch-tools-chroot"/>.</para>
    162162        </listitem>
    … …  
    165165    </variablelist>
    166166
    167     <para>Fix hardcoded path to the executable loader in
     167    <para>Fix a hard coded path to the executable loader in the
    168168    <command>ldd</command> script:</para>
    169169
    … …  
    186186          <filename>/lib/ld-linux-aarch64_be.so.1</filename>.</para>
    187187
    188       <para>If the output is not shown as above or there was no output at all,
     188      <para>If the output is not as shown above, or there is no output at all,
    189189      then something is wrong. Investigate and retrace the steps to find out
    190190      where the problem is and correct it. This issue must be resolved before
    191       continuing on.</para>
     191      continuing.</para>
    192192
    193193      <para>Once all is well, clean up the test file:</para>
    … …  
    197197    </caution>
    198198
    199     <note><para>Building packages in the next chapter will serve as an
     199    <note><para>Building the packages in the next chapter will serve as an
    200200    additional check that the toolchain has been built properly. If some
    201     package, especially binutils-pass2 or gcc-pass2, fails to build, it is
     201    package, especially Binutils-pass2 or GCC-pass2, fails to build, it is
    202202    an indication that something has gone wrong with the
    203     previous Binutils, GCC, or Glibc installations.</para></note>
     203    preceding Binutils, GCC, or Glibc installations.</para></note>
    204204
    205205    <para>Now that our cross-toolchain is complete, finalize the installation
    206     of the limits.h header. For doing so, run a utility provided by the GCC
     206    of the limits.h header. To do this, run a utility provided by the GCC
    207207    developers:</para>
    208208

  • chapter05/libstdc++.xml

    rad85e5b r9974e9b  
    2929    (part of GCC is written in C++), but we had to defer its installation
    3030    when we built <xref linkend="ch-tools-gcc-pass1"/>
    31     because it depends on glibc, which was not yet available in the target
     31    because Libstdc++ depends on Glibc, which was not yet available in the target
    3232    directory.
    3333    </para>
    … …  
    5454    </note>
    5555
    56     <para>Create a separate build directory for libstdc++ and enter it:</para>
     56    <para>Create a separate build directory for Libstdc++ and enter it:</para>
    5757
    5858<screen><userinput remap="pre">mkdir -v build
    5959cd       build</userinput></screen>
    6060
    61     <para>Prepare libstdc++ for compilation:</para>
     61    <para>Prepare Libstdc++ for compilation:</para>
    6262
    6363<screen><userinput remap="configure">../libstdc++-v3/configure           \
    … …  
    7676        <term><parameter>--host=...</parameter></term>
    7777        <listitem>
    78           <para>Specifies that the cross compiler we have just built
     78          <para>Specifies that the cross-compiler we have just built
    7979          should be used instead of the one in
    8080          <filename>/usr/bin</filename>.</para>
    … …  
    9494        <listitem>
    9595          <para>This specifies the installation directory for include files.
    96           Because libstdc++ is the standard C++ library for LFS, this
     96          Because Libstdc++ is the standard C++ library for LFS, this
    9797          directory should match the location where the C++ compiler
    9898          (<command>$LFS_TGT-g++</command>) would search for the
    9999          standard C++ include files. In a normal build, this information
    100           is automatically passed to the libstdc++ <command>configure</command>
     100          is automatically passed to the Libstdc++ <command>configure</command>
    101101          options from the top level directory. In our case, this information
    102102          must be explicitly given.
    103103          The C++ compiler will prepend the sysroot path
    104           <filename class="directory">$LFS</filename> (specified building
    105           GCC pass 1) to the include file search path, so it will actually
     104          <filename class="directory">$LFS</filename> (specified when building
     105          GCC-pass1) to the include file search path, so it will actually
    106106          search in
    107107          <filename class="directory">$LFS/tools/$LFS_TGT/include/c++/&gcc-version;</filename>.
    108108          The combination of the <parameter>DESTDIR</parameter>
    109109          variable (in the <command>make install</command> command below)
    110           and this switch ensures to install the headers there.</para>
     110          and this switch causes the headers to be installed there.</para>
    111111        </listitem>
    112112      </varlistentry>
    … …  
    114114    </variablelist>
    115115
    116     <para>Compile libstdc++ by running:</para>
     116    <para>Compile Libstdc++ by running:</para>
    117117
    118118<screen><userinput remap="make">make</userinput></screen>
    … …  
    123123
    124124    <para>Remove the libtool archive files because they are harmful for
    125     cross compilation:</para>
     125    cross-compilation:</para>
    126126
    127127<screen><userinput remap="install">rm -v $LFS/usr/lib/lib{stdc++,stdc++fs,supc++}.la</userinput></screen>

  • part3intro/toolchaintechnotes.xml

    rad85e5b r9974e9b  
    4141      <para>
    4242        The LFS book is not (and does not contain) a general tutorial to
    43         build a cross (or native) toolchain. Don't use the commands in the
    44         book for a cross toolchain for some purpose other
     43        build a cross- (or native) toolchain. Don't use the commands in the
     44        book for a cross-toolchain for some purpose other
    4545        than building LFS, unless you really understand what you are doing.
    4646      </para>
    … …  
    7575
    7676    <para>As an example, let us imagine the following scenario (sometimes
    77     referred to as <quote>Canadian Cross</quote>): we have a
     77    referred to as <quote>Canadian Cross</quote>). We have a
    7878    compiler on a slow machine only, let's call it machine A, and the compiler
    7979    ccA. We also have a fast machine (B), but no compiler for (B), and we
    … …  
    146146
    147147    <note>
    148       <para>All packages involved with cross compilation in the book use an
     148      <para>All the cross-compiled packages in this book use an
    149149      autoconf-based building system.  The autoconf-based building system
    150150      accepts system types in the form cpu-vendor-kernel-os,
    151       referred to as the system triplet.  Since the vendor field is mostly
    152       irrelevant, autoconf allows to omit it. An astute reader may wonder
     151      referred to as the system triplet.  Since the vendor field is often
     152      irrelevant, autoconf lets you omit it.</para>
     153     
     154      <para>An astute reader may wonder
    153155      why a <quote>triplet</quote> refers to a four component name. The
    154       reason is the kernel field and the os field originated from one
     156      kernel field and the os field began as a single
    155157      <quote>system</quote> field.  Such a three-field form is still valid
    156       today for some systems, for example
    157       <literal>x86_64-unknown-freebsd</literal>.  But for other systems,
    158       two systems can share the same kernel but still be too different to
    159       use a same triplet for them.  For example, an Android running on a
     158      today for some systems, for example,
     159      <literal>x86_64-unknown-freebsd</literal>.  But
     160      two systems can share the same kernel and still be too different to
     161      use the same triplet to describe them.  For example, Android running on a
    160162      mobile phone is completely different from Ubuntu running on an ARM64
    161       server, despite they are running on the same type of CPU (ARM64) and
    162       using the same kernel (Linux).
    163       Without an emulation layer, you cannot run an
    164       executable for the server on the mobile phone or vice versa.  So the
    165       <quote>system</quote> field is separated into kernel and os fields to
    166       designate these systems unambiguously.  For our example, the Android
     163      server, even though they are both running on the same type of CPU (ARM64) and
     164      using the same kernel (Linux).</para>
     165     
     166      <para>Without an emulation layer, you cannot run an
     167      executable for a server on a mobile phone or vice versa.  So the
     168      <quote>system</quote> field has been divided into kernel and os fields, to
     169      designate these systems unambiguously.  In our example, the Android
    167170      system is designated <literal>aarch64-unknown-linux-android</literal>,
    168171      and the Ubuntu system is designated
    169       <literal>aarch64-unknown-linux-gnu</literal>.  The word
    170       <quote>triplet</quote> remained. A simple way to determine your
     172      <literal>aarch64-unknown-linux-gnu</literal>.</para>
     173     
     174      <para>The word <quote>triplet</quote> remains embedded in the lexicon. A simple way to determine your
    171175      system triplet is to run the <command>config.guess</command>
    172176      script that comes with the source for many packages. Unpack the binutils
    173       sources and run the script: <userinput>./config.guess</userinput> and note
     177      sources, run the script <userinput>./config.guess</userinput>, and note
    174178      the output. For example, for a 32-bit Intel processor the
    175179      output will be <emphasis>i686-pc-linux-gnu</emphasis>. On a 64-bit
    … …  
    194198    </note>
    195199
    196     <para>In order to fake a cross compilation in LFS, the name of the host triplet
     200    <para>In order to fake a cross-compilation in LFS, the name of the host triplet
    197201    is slightly adjusted by changing the &quot;vendor&quot; field in the
    198202    <envar>LFS_TGT</envar> variable so it says &quot;lfs&quot;. We also use the
    199     <parameter>--with-sysroot</parameter> option when building the cross linker and
    200     cross compiler to tell them where to find the needed host files. This
     203    <parameter>--with-sysroot</parameter> option when building the cross-linker and
     204    cross-compiler to tell them where to find the needed host files. This
    201205    ensures that none of the other programs built in <xref
    202206    linkend="chapter-temporary-tools"/> can link to libraries on the build
    … …  
    238242    just a compiler, but also defines a standard library. In this book, the
    239243    GNU C library, named glibc, is used (there is an alternative, &quot;musl&quot;). This library must
    240     be compiled for the LFS machine; that is, using the cross compiler cc1.
    241     But the compiler itself uses an internal library implementing complex
     244    be compiled for the LFS machine; that is, using the cross-compiler cc1.
     245    But the compiler itself uses an internal library providing complex
    242246    subroutines for functions not available in the assembler instruction set. This
    243247    internal library is named libgcc, and it must be linked to the glibc
    244     library to be fully functional! Furthermore, the standard library for
     248    library to be fully functional. Furthermore, the standard library for
    245249    C++ (libstdc++) must also be linked with glibc. The solution to this
    246250    chicken and egg problem is first to build a degraded cc1-based libgcc,
    … …  
    250254    functionality of libgcc.</para>
    251255
    252     <para>This is not the end of the story: the upshot of the preceding
    253     paragraph is that cc1 is unable to build a fully functional libstdc++, but
    254     this is the only compiler available for building the C/C++ libraries
    255     during stage 2! Of course, the compiler built during stage 2, cc-lfs,
    256     would be able to build those libraries, but (1) the build system of
    257     gcc does not know that it is usable on pc, and (2) using it on pc
    258     would create a risk of linking to the pc libraries, since cc-lfs is a native
    259     compiler. So we have to re-build libstdc++ later as a part of
    260     gcc stage 2.</para>
    261 
    262     <para>In &ch-final; (or <quote>stage 3</quote>), all packages needed for
    263     the LFS system are built. Even if a package is already installed into
    264     the LFS system in a previous chapter, we still rebuild the package
    265     unless we are completely sure it's unnecessary.  The main reason for
    266     rebuilding these packages is to settle them down: if we reinstall a LFS
     256    <para>The upshot of the preceding paragraph is that cc1 is unable to
     257    build a fully functional libstdc++ with the degraded libgcc, but cc1
     258    is the only compiler available for building the C/C++ libraries
     259    during stage 2. Of course, the compiler built by stage 2, cc-lfs,
     260    would be able to build those libraries, but:</para>
     261
     262    <itemizedlist>
     263      <listitem>
     264        <para>
     265          Generally cc-lfs cannot run on pc (the host distro).  Despite the
     266          triplets of pc and lfs are compatible to each other, an executable
     267          for lfs will depend on glibc-&glibc-version; while the host distro
     268          may utilize a different libc implementation (for example, musl) or
     269          a previous release of glibc (for example, glibc-2.13).
     270        </para>
     271      </listitem>
     272      <listitem>
     273        <para>
     274          Even if cc-lfs happens to run on pc, using it on pc would create
     275          a risk of linking to the pc libraries, since cc-lfs is a native
     276          compiler.
     277        </para>
     278      </listitem>
     279    </itemizedlist>
     280
     281    <para>So when we build gcc stage 2, we instruct the building system to
     282    rebuild libgcc and libstdc++ with cc1, but link libstdc++ to the newly
     283    rebuilt libgcc instead of the degraded build.  Then the rebuilt
     284    libstdc++ will be fully functional.</para>
     285
     286    <para>In &ch-final; (or <quote>stage 3</quote>), all the packages needed for
     287    the LFS system are built. Even if a package has already been installed into
     288    the LFS system in a previous chapter, we still rebuild the package.  The main reason for
     289    rebuilding these packages is to make them stable: if we reinstall a LFS
    267290    package on a complete LFS system, the installed content of the package
    268     should be same as the content of the same package installed in
     291    should be the same as the content of the same package when installed in
    269292    &ch-final;.  The temporary packages installed in &ch-tmp-cross; or
    270     &ch-tmp-chroot; cannot satisfy this expectation because some of them
    271     are built without optional dependencies installed, and autoconf cannot
    272     perform some feature checks in &ch-tmp-cross; because of cross
    273     compilation, causing the temporary packages to lack optional features
     293    &ch-tmp-chroot; cannot satisfy this requirement, because some of them
     294    are built without optional dependencies, and autoconf cannot
     295    perform some feature checks in &ch-tmp-cross; because of cross-compilation,
     296    causing the temporary packages to lack optional features,
    274297    or use suboptimal code routines. Additionally, a minor reason for
    275     rebuilding the packages is allowing to run the testsuite.</para>
     298    rebuilding the packages is to run the test suites.</para>
    276299
    277300  </sect2>
    … …  
    279302  <sect2 id="other-details">
    280303
    281     <title>Other procedural details</title>
     304    <title>Other Procedural Details</title>
    282305
    283306    <para>The cross-compiler will be installed in a separate <filename
    … …  
    301324    <command>ld</command> by passing it the <parameter>--verbose</parameter>
    302325    flag. For example, <command>$LFS_TGT-ld --verbose | grep SEARCH</command>
    303     will illustrate the current search paths and their order. Note that this
    304     example can be run as shown only while being user
     326    will illustrate the current search paths and their order. (Note that this
     327    example can be run as shown only while logged in as user
    305328    <systemitem class="username">lfs</systemitem>. If you come back to this
    306     page later, replace <command>$LFS_TGT-ld</command> with just
    307     <command>ld</command>.</para>
     329    page later, replace <command>$LFS_TGT-ld</command> with
     330    <command>ld</command>).</para>
    308331
    309332    <para>The next package installed is gcc. An example of what can be
    … …  
    318341    operation of <command>gcc</command> itself, the same search paths are not
    319342    necessarily used. To find out which standard linker <command>gcc</command>
    320     will use, run: <command>$LFS_TGT-gcc -print-prog-name=ld</command>. Again,
    321     remove the <command>$LFS_TGT-</command> part if coming back to this
    322     later.</para>
     343    will use, run: <command>$LFS_TGT-gcc -print-prog-name=ld</command>. (Again,
     344    remove the <command>$LFS_TGT-</command> prefix if coming back to this
     345    later.)</para>
    323346
    324347    <para>Detailed information can be obtained from <command>gcc</command> by
    … …  
    326349    a program. For example, <command>$LFS_TGT-gcc -v
    327350    <replaceable>example.c</replaceable></command> (or without <command>
    328     $LFS_TGT-</command> if coming back later to this) will show
     351    $LFS_TGT-</command> if coming back later) will show
    329352    detailed information about the preprocessor, compilation, and assembly
    330353    stages, including <command>gcc</command>'s search paths for included
    331354    headers and their order.</para>
    332355
    333     <para>Next installed are sanitized Linux API headers. These allow the
     356    <para>Next up: sanitized Linux API headers. These allow the
    334357    standard C library (glibc) to interface with features that the Linux
    335358    kernel will provide.</para>
    336359
    337     <para>The next package installed is glibc. The most important
     360    <para>Next comes glibc. The most important
    338361    considerations for building glibc are the compiler, binary tools, and
    339362    kernel headers. The compiler is generally not an issue since glibc will
    340363    always use the compiler relating to the <parameter>--host</parameter>
    341     parameter passed to its configure script; e.g. in our case, the compiler
     364    parameter passed to its configure script; e.g., in our case, the compiler
    342365    will be <command>$LFS_TGT-gcc</command>. The binary tools and kernel
    343366    headers can be a bit more complicated. Therefore, we take no risks and use
    … …  
    351374    <parameter>-isystem</parameter> flags to control the compiler's include
    352375    search path. These items highlight an important aspect of the glibc
    353     package&mdash;it is very self-sufficient in terms of its build machinery
     376    package&mdash;it is very self-sufficient in terms of its build machinery,
    354377    and generally does not rely on toolchain defaults.</para>
    355378
    356379    <para>As mentioned above, the standard C++ library is compiled next, followed in
    357     <xref linkend="chapter-temporary-tools"/> by other programs that need
    358     to be cross compiled for breaking circular dependencies at build time.
     380    <xref linkend="chapter-temporary-tools"/> by other programs that must
     381    be cross-compiled to break circular dependencies at build time.
    359382    The install step of all those packages uses the
    360383    <envar>DESTDIR</envar> variable to force installation
    … …  
    378401    core toolchain is self-contained and self-hosted. In
    379402    <xref linkend="chapter-building-system"/>, final versions of all the
    380     packages needed for a fully functional system are built, tested and
     403    packages needed for a fully functional system are built, tested, and
    381404    installed.</para>
    382405

  • prologue/errata.xml

    rad85e5b r9974e9b  
    2222
    2323  <para>In addition, the Linux From Scratch editors maintain a list of security
    24   vulnerabilities discovered <emphasis>after</emphasis> a book has been released. To see
    25   whether there  are any known security vulnerabilities, please visit
    26   <ulink url="&secadv;"/> before proceeding with your build. You should also continue
    27   to consult the advisories, and fix any security vulnerabilities, even
    28   when the LFS system has been completely constructed.</para>
     24  vulnerabilities discovered <emphasis>after</emphasis> a book has been released. To read the list, please visit
     25  <ulink url="&secadv;"/> before proceeding with your build. You should apply
     26  the changes suggested by the advisories to the relevant sections of the
     27  book as you build the LFS system.  And, if you will use the LFS system as
     28  a real desktop or server system, you should continue to consult the
     29  advisories and fix any security vulnerabilities, even when the LFS system
     30  has been completely constructed.</para>
    2931
    3032</sect1>
Note: See TracChangeset for help on using the changeset viewer.