diff --git a/general.ent b/general.ent
index 1328f7c7c..81a7b51dc 100644
--- a/general.ent
+++ b/general.ent
@@ -123,6 +123,9 @@
 <!ENTITY lfs-user        "<systemitem class='username'>lfs</systemitem>">
 <!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">
 %packages-entities;
diff --git a/part3intro/toolchaintechnotes.xml b/part3intro/toolchaintechnotes.xml
index 49656d052..16b6aafd2 100644
--- a/part3intro/toolchaintechnotes.xml
+++ b/part3intro/toolchaintechnotes.xml
@@ -145,15 +145,30 @@
     <title>Implementation of Cross-Compilation for LFS</title>
 
     <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
       the output. For example, for a 32-bit Intel processor the
@@ -241,8 +256,23 @@
     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
     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>