Changeset d11d449

Timestamp:

09/30/2022 04:12:01 PM (19 months ago)

Author:

Bruce Dubbs <bdubbs@…>

Branches:

11.3, 11.3-rc1, 12.0, 12.0-rc1, 12.1, 12.1-rc1, bdubbs/gcc13, multilib, renodr/libudev-from-systemd, trunk, xry111/arm64, xry111/arm64-12.0, xry111/clfs-ng, xry111/loongarch, xry111/loongarch-12.0, xry111/loongarch-12.1, xry111/mips64el, xry111/pip3, xry111/rust-wip-20221008, xry111/update-glibc

Children:

52ddd6c

Parents:

488b43a (diff), 543c94c (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 branch 'trunk' of git.linuxfromscratch.org:lfs into trunk

Files:

• general.ent (modified) (1 diff)
• part3intro/toolchaintechnotes.xml (modified) (2 diffs)

general.ent

@@ -124 +124 @@
 <!ENTITY fstab           "<filename>/etc/fstab</filename>">
 <!ENTITY boot-dir        "<filename class='directory'>/boot</filename>">
+<!ENTITY ch-final        "<xref linkend='chapter-building-system'/>">
+<!ENTITY ch-tmp-cross    "<xref linkend='chapter-temporary-tools'/>">
+<!ENTITY ch-tmp-chroot   "<xref linkend='chapter-chroot-temporary-tools'/>">
 
 <!ENTITY % packages-entities SYSTEM "packages.ent">

part3intro/toolchaintechnotes.xml

@@ -146 +146 @@
 
     <note>
-      <para>Almost all the build systems use names of the form
-      cpu-vendor-kernel-os, referred to as the machine triplet. (Sometimes,
-      the vendor field is omitted.) An astute
-      reader may wonder why a <quote>triplet</quote> refers to a four component
-      name. The reason is historical: initially, three component names were enough
-      to designate a machine unambiguously, but as new machines and systems
-      proliferated, that proved insufficient. The word <quote>triplet</quote>
-      remained. A simple way to determine your machine triplet is to run
-      the <command>config.guess</command>
+      <para>All packages involved with cross compilation in the book 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
+      why a <quote>triplet</quote> refers to a four component name. The
+      reason is the kernel field and the os field originiated from one
+      <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
+      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
+      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
+      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
@@ -242 +257 @@
     gcc does not know that it is usable on pc, and (2) using it 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++ twice later on: as a part of
-    gcc stage 2, and then again in the chroot environment (gcc stage 3).</para>
+    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
+    package on a complete LFS system, the installed content of the package
+    should be same as the content of the same package installed in
+    &ch-final;.  The temporary packages installed in &ch-tmp-cross; or
+    &ch-tmp-chroot; cannot satisify 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
+    or use suboptimal code routines. Additionally, a minor reason for
+    rebuilding the packages is allowing to run the testsuite.</para>
 
   </sect2>