Changeset 981e0c4

Timestamp:

10/28/2022 10:30:10 PM (18 months ago)

Author:

Thomas Trepl (Moody) <thomas@…>

Branches:

multilib

Children:

07fd8bf8

Parents:

f9e8271 (diff), c389124 (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:

Automatic merge of trunk into multilib

Files:

• chapter04/addinguser.xml (modified) (2 diffs)
• chapter04/settingenviron.xml (modified) (9 diffs)
• part3intro/toolchaintechnotes.xml (modified) (12 diffs)

chapter04/addinguser.xml

@@ -63 +63 @@
       <term><parameter>lfs</parameter></term>
       <listitem>
-        <para>This is the actual name for the created user.</para>
+        <para>This is the name of the new user.</para>
       </listitem>
     </varlistentry>
@@ -72 +72 @@
   non-&root; user (as opposed to switching to user &lfs-user;
   when logged in as &root;, which does not require the &lfs-user; user to
-  have a password), you need to set a password of &lfs-user;.  Issue the
+  have a password), you need to set a password for &lfs-user;.  Issue the
   following command as the &root; user to set the password:</para>
 

chapter04/settingenviron.xml

@@ -20 +20 @@
 EOF</userinput></screen>
 
-  <para>When logged on as user <systemitem class="username">lfs</systemitem>
-  or switched to the &lfs-user; user using a <command>su</command> command
-  with <quote><parameter>-</parameter></quote> option,
+  <para>When logged on as user <systemitem class="username">lfs</systemitem>,
+  or when switched to the &lfs-user; user using an <command>su</command> command
+  with the <quote><parameter>-</parameter></quote> option,
   the initial shell is a <emphasis>login</emphasis> shell which reads
   the <filename>/etc/profile</filename> of the host (probably containing some
@@ -31 +31 @@
   <envar>TERM</envar>, and <envar>PS1</envar> variables. This ensures that no
   unwanted and potentially hazardous environment variables from the host system
-  leak into the build environment. The technique used here achieves the goal of
-  ensuring a clean environment.</para>
+  leak into the build environment.</para>
 
   <para>The new instance of the shell is a <emphasis>non-login</emphasis>
@@ -115 +114 @@
   Setting <envar>LC_ALL</envar> to <quote>POSIX</quote> or <quote>C</quote>
   (the two are equivalent) ensures that everything will work as expected in
-  the chroot environment.</para>
+  the cross-compilation environment.</para>
       </listitem>
     </varlistentry>
@@ -123 +122 @@
       <listitem>
   <para>The <envar>LFS_TGT</envar> variable sets a non-default, but compatible machine
-  description for use when building our cross compiler and linker and when cross
-  compiling our temporary toolchain. More information is contained in
+  description for use when building our cross-compiler and linker and when
+  cross-compiling our temporary toolchain. More information is provided by
   <xref linkend="ch-tools-toolchaintechnotes" role=""/>.</para>
       </listitem>
@@ -147 +146 @@
       <listitem>
   <para>If <filename class="directory">/bin</filename> is not a symbolic
-  link, then it has to be added to the <envar>PATH</envar> variable.</para>
+  link, it must be added to the <envar>PATH</envar> variable.</para>
       </listitem>
     </varlistentry>
@@ -178 +177 @@
       <term><parameter>export ...</parameter></term>
       <listitem>
-        <para>While the above commands have set some variables, in order
+        <para>While the preceding commands have set some variables, in order
         to make them visible within any sub-shells, we export them.</para>
       </listitem>
@@ -187 +186 @@
   <important>
 
-     <para>Several commercial distributions add a non-documented instantiation
+     <para>Several commercial distributions add an undocumented instantiation
      of <filename>/etc/bash.bashrc</filename> to the initialization of
      <command>bash</command>. This file has the potential to modify the
@@ -200 +199 @@
      <screen role="nodump"><userinput>[ ! -e /etc/bash.bashrc ] || mv -v /etc/bash.bashrc /etc/bash.bashrc.NOUSE</userinput></screen>
 
-     <para>After use of the <systemitem class="username">lfs</systemitem>
-     user is finished at the beginning of <xref
-     linkend="chapter-chroot-temporary-tools"/>, you can restore
+     <para>When the <systemitem class="username">lfs</systemitem>
+     user is no longer needed (at the beginning of <xref
+     linkend="chapter-chroot-temporary-tools"/>), you may safely restore
      <filename>/etc/bash.bashrc</filename> (if desired).</para>
 
@@ -211 +210 @@
   </important>
 
-  <para>Finally, to have the environment fully prepared for building the
+  <para>Finally, to ensure the environment is fully prepared for building the
   temporary tools, force the <command>bash</command> shell to read
   the new user profile:</para>

part3intro/toolchaintechnotes.xml

@@ -41 +41 @@
       <para>
         The LFS book is not (and does not contain) a general tutorial to
-        build a cross (or native) toolchain. Don't use the commands in the
-        book for a cross toolchain for some purpose other
+        build a cross- (or native) toolchain. Don't use the commands in the
+        book for a cross-toolchain for some purpose other
         than building LFS, unless you really understand what you are doing.
       </para>
@@ -75 +75 @@
 
     <para>As an example, let us imagine the following scenario (sometimes
-    referred to as <quote>Canadian Cross</quote>): we have a
+    referred to as <quote>Canadian Cross</quote>). We have a
     compiler on a slow machine only, let's call it machine A, and the compiler
     ccA. We also have a fast machine (B), but no compiler for (B), and we
@@ -146 +146 @@
 
     <note>
-      <para>All packages involved with cross compilation in the book use an
+      <para>All the packages involved with cross-compilation use an
       autoconf-based building system.  The autoconf-based building system
       accepts system types in the form cpu-vendor-kernel-os,
-      referred to as the system triplet.  Since the vendor field is mostly
-      irrelevant, autoconf allows to omit it. An astute reader may wonder
+      referred to as the system triplet.  Since the vendor field is often
+      irrelevant, autoconf lets you omit it.</para>
+      
+      <para>An astute reader may wonder
       why a <quote>triplet</quote> refers to a four component name. The
-      reason is the kernel field and the os field originated from one
+      kernel field and the os field began as a single
       <quote>system</quote> field.  Such a three-field form is still valid
-      today for some systems, for example
-      <literal>x86_64-unknown-freebsd</literal>.  But for other systems,
-      two systems can share the same kernel but still be too different to
-      use a same triplet for them.  For example, an Android running on a
+      today for some systems, for example,
+      <literal>x86_64-unknown-freebsd</literal>.  But
+      two systems can share the same kernel and still be too different to
+      use the same triplet to describe them.  For example, Android running on a
       mobile phone is completely different from Ubuntu running on an ARM64
-      server, despite they are running on the same type of CPU (ARM64) and
-      using the same kernel (Linux).
-      Without an emulation layer, you cannot run an
-      executable for the server on the mobile phone or vice versa.  So the
-      <quote>system</quote> field is separated into kernel and os fields to
-      designate these systems unambiguously.  For our example, the Android
+      server, even though they are both running on the same type of CPU (ARM64) and
+      using the same kernel (Linux).</para>
+      
+      <para>Without an emulation layer, you cannot run an
+      executable for a server on a mobile phone or vice versa.  So the
+      <quote>system</quote> field has been divided into kernel and os fields, to
+      designate these systems unambiguously.  In our example, the Android
       system is designated <literal>aarch64-unknown-linux-android</literal>,
       and the Ubuntu system is designated
-      <literal>aarch64-unknown-linux-gnu</literal>.  The word
-      <quote>triplet</quote> remained. A simple way to determine your
+      <literal>aarch64-unknown-linux-gnu</literal>.</para>
+      
+      <para>The word <quote>triplet</quote> remains embedded in the lexicon. A simple way to determine your
       system triplet is to run the <command>config.guess</command>
       script that comes with the source for many packages. Unpack the binutils
-      sources and run the script: <userinput>./config.guess</userinput> and note
+      sources, run the script <userinput>./config.guess</userinput>, and note
       the output. For example, for a 32-bit Intel processor the
       output will be <emphasis>i686-pc-linux-gnu</emphasis>. On a 64-bit
@@ -194 +198 @@
     </note>
 
-    <para>In order to fake a cross compilation in LFS, the name of the host triplet
+    <para>In order to fake a cross-compilation in LFS, the name of the host triplet
     is slightly adjusted by changing the &quot;vendor&quot; field in the
     <envar>LFS_TGT</envar> variable so it says &quot;lfs&quot;. We also use the
-    <parameter>--with-sysroot</parameter> option when building the cross linker and
-    cross compiler to tell them where to find the needed host files. This
+    <parameter>--with-sysroot</parameter> option when building the cross-linker and
+    cross-compiler to tell them where to find the needed host files. This
     ensures that none of the other programs built in <xref
     linkend="chapter-temporary-tools"/> can link to libraries on the build
@@ -238 +242 @@
     just a compiler, but also defines a standard library. In this book, the
     GNU C library, named glibc, is used (there is an alternative, &quot;musl&quot;). This library must
-    be compiled for the LFS machine; that is, using the cross compiler cc1.
-    But the compiler itself uses an internal library implementing complex
+    be compiled for the LFS machine; that is, using the cross-compiler cc1.
+    But the compiler itself uses an internal library providing complex
     subroutines for functions not available in the assembler instruction set. This
     internal library is named libgcc, and it must be linked to the glibc
-    library to be fully functional! Furthermore, the standard library for
+    library to be fully functional. Furthermore, the standard library for
     C++ (libstdc++) must also be linked with glibc. The solution to this
     chicken and egg problem is first to build a degraded cc1-based libgcc,
@@ -250 +254 @@
     functionality of libgcc.</para>
 
-    <para>This is not the end of the story: the upshot of the preceding
+    <para>The upshot of the preceding
     paragraph is that cc1 is unable to build a fully functional libstdc++, but
     this is the only compiler available for building the C/C++ libraries
-    during stage 2! Of course, the compiler built during stage 2, cc-lfs,
+    during stage 2. Of course, the compiler built by stage 2, cc-lfs,
     would be able to build those libraries, but (1) the build system of
-    gcc does not know that it is usable on pc, and (2) using it on pc
+    gcc does not know cc-lfs can run on pc, and (2) using cc-lfs on pc
     would create a risk of linking to the pc libraries, since cc-lfs is a native
     compiler. So we have to re-build libstdc++ later as a part of
     gcc stage 2.</para>
 
-    <para>In &ch-final; (or <quote>stage 3</quote>), all packages needed for
-    the LFS system are built. Even if a package is already installed into
-    the LFS system in a previous chapter, we still rebuild the package
-    unless we are completely sure it's unnecessary.  The main reason for
-    rebuilding these packages is to settle them down: if we reinstall a LFS
+    <para>In &ch-final; (or <quote>stage 3</quote>), all the packages needed for
+    the LFS system are built. Even if a package has already been installed into
+    the LFS system in a previous chapter, we still rebuild the package.  The main reason for
+    rebuilding these packages is to make them stable: if we reinstall a LFS
     package on a complete LFS system, the installed content of the package
-    should be same as the content of the same package installed in
+    should be the same as the content of the same package when installed in
     &ch-final;.  The temporary packages installed in &ch-tmp-cross; or
-    &ch-tmp-chroot; cannot satisfy this expectation because some of them
-    are built without optional dependencies installed, and autoconf cannot
-    perform some feature checks in &ch-tmp-cross; because of cross
-    compilation, causing the temporary packages to lack optional features
+    &ch-tmp-chroot; cannot satisfy this requirement, because some of them
+    are built without optional dependencies, and autoconf cannot
+    perform some feature checks in &ch-tmp-cross; because of cross-compilation,
+    causing the temporary packages to lack optional features,
     or use suboptimal code routines. Additionally, a minor reason for
-    rebuilding the packages is allowing to run the testsuite.</para>
+    rebuilding the packages is to run the test suites.</para>
 
   </sect2>
@@ -279 +282 @@
   <sect2 id="other-details">
 
-    <title>Other procedural details</title>
+    <title>Other Procedural Details</title>
 
     <para>The cross-compiler will be installed in a separate <filename
@@ -301 +304 @@
     <command>ld</command> by passing it the <parameter>--verbose</parameter>
     flag. For example, <command>$LFS_TGT-ld --verbose | grep SEARCH</command>
-    will illustrate the current search paths and their order. Note that this
-    example can be run as shown only while being user
+    will illustrate the current search paths and their order. (Note that this
+    example can be run as shown only while logged in as user
     <systemitem class="username">lfs</systemitem>. If you come back to this
-    page later, replace <command>$LFS_TGT-ld</command> with just
-    <command>ld</command>.</para>
+    page later, replace <command>$LFS_TGT-ld</command> with
+    <command>ld</command>).</para>
 
     <para>The next package installed is gcc. An example of what can be
@@ -318 +321 @@
     operation of <command>gcc</command> itself, the same search paths are not
     necessarily used. To find out which standard linker <command>gcc</command>
-    will use, run: <command>$LFS_TGT-gcc -print-prog-name=ld</command>. Again,
-    remove the <command>$LFS_TGT-</command> part if coming back to this
-    later.</para>
+    will use, run: <command>$LFS_TGT-gcc -print-prog-name=ld</command>. (Again,
+    remove the <command>$LFS_TGT-</command> prefix if coming back to this
+    later.)</para>
 
     <para>Detailed information can be obtained from <command>gcc</command> by
@@ -326 +329 @@
     a program. For example, <command>$LFS_TGT-gcc -v
     <replaceable>example.c</replaceable></command> (or without <command>
-    $LFS_TGT-</command> if coming back later to this) will show
+    $LFS_TGT-</command> if coming back later) will show
     detailed information about the preprocessor, compilation, and assembly
     stages, including <command>gcc</command>'s search paths for included
     headers and their order.</para>
 
-    <para>Next installed are sanitized Linux API headers. These allow the
+    <para>Next up: sanitized Linux API headers. These allow the
     standard C library (glibc) to interface with features that the Linux
     kernel will provide.</para>
 
-    <para>The next package installed is glibc. The most important
+    <para>Next comes glibc. The most important
     considerations for building glibc are the compiler, binary tools, and
     kernel headers. The compiler is generally not an issue since glibc will
     always use the compiler relating to the <parameter>--host</parameter>
-    parameter passed to its configure script; e.g. in our case, the compiler
+    parameter passed to its configure script; e.g., in our case, the compiler
     will be <command>$LFS_TGT-gcc</command>. The binary tools and kernel
     headers can be a bit more complicated. Therefore, we take no risks and use
@@ -351 +354 @@
     <parameter>-isystem</parameter> flags to control the compiler's include
     search path. These items highlight an important aspect of the glibc
-    package&mdash;it is very self-sufficient in terms of its build machinery
+    package&mdash;it is very self-sufficient in terms of its build machinery,
     and generally does not rely on toolchain defaults.</para>
 
     <para>As mentioned above, the standard C++ library is compiled next, followed in
-    <xref linkend="chapter-temporary-tools"/> by other programs that need
-    to be cross compiled for breaking circular dependencies at build time.
+    <xref linkend="chapter-temporary-tools"/> by other programs that must
+    be cross-compiled to break circular dependencies at build time.
     The install step of all those packages uses the
     <envar>DESTDIR</envar> variable to force installation
@@ -378 +381 @@
     core toolchain is self-contained and self-hosted. In
     <xref linkend="chapter-building-system"/>, final versions of all the
-    packages needed for a fully functional system are built, tested and
+    packages needed for a fully functional system are built, tested, and
     installed.</para>