From e18ba697ebe7861e70b00dfb1480273f7ea9b40c Mon Sep 17 00:00:00 2001 From: Xi Ruoyao Date: Fri, 30 Sep 2022 10:39:03 +0800 Subject: [PATCH 1/3] toolchain technical note: rewrite the descrption for triplet - Don't say "most building system", refine the dicussion for autoconf. Other building systems may use a variant of triplet, or use a completely different system designation. - Explain why a triplet may contain 4 fields in detail. "Histroical reason" is not really correct because 3-field triplet is still used today for BSD, Fuchsia, IOS, Mac OS X (darwin), Solaris, etc. - "machine" triplet to "system" triplet (strictly speaking, only the first field in the triplet is for the machine). Why we need to say "vendor can be omitted" explicitly: we mention "gcc -dumpmachine". On some distros (like Ubuntu) the output has no vendor field. If you think this is too nasty, please remove both. --- part3intro/toolchaintechnotes.xml | 31 ++++++++++++++++++++++--------- 1 file changed, 22 insertions(+), 9 deletions(-) diff --git a/part3intro/toolchaintechnotes.xml b/part3intro/toolchaintechnotes.xml index 49656d052..7a8058424 100644 --- a/part3intro/toolchaintechnotes.xml +++ b/part3intro/toolchaintechnotes.xml @@ -145,15 +145,28 @@ Implementation of Cross-Compilation for LFS - 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 triplet 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 triplet - remained. A simple way to determine your machine triplet is to run - the config.guess + 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 triplet refers to a four component name. The + reason is the kernel field and the os field originiated from one + system field. Such a three-field form is still valid + today for some systems, for example + x86_64-unknown-freebsd. 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. Without an emulation layer, you cannot run an executable for + the server on the mobile phone or vice versa. So the + system field is separated into kernel and os fields to + designate these systems unambiguously. For our example, the Android + system is designated aarch64-unknown-linux-android, + and the Ubuntu system is designated + aarch64-unknown-linux-gnu. The word + triplet remained. A simple way to determine your + system triplet is to run the config.guess script that comes with the source for many packages. Unpack the binutils sources and run the script: ./config.guess and note the output. For example, for a 32-bit Intel processor the From 77b46db0a84285c86a4963c6fea9f3ec1b45d8f4 Mon Sep 17 00:00:00 2001 From: Xi Ruoyao Date: Fri, 30 Sep 2022 16:22:20 +0800 Subject: [PATCH 2/3] toolchaintechnotes: highlight why the example (ubuntu vs android) needs "os" field --- part3intro/toolchaintechnotes.xml | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/part3intro/toolchaintechnotes.xml b/part3intro/toolchaintechnotes.xml index 7a8058424..a6206bb91 100644 --- a/part3intro/toolchaintechnotes.xml +++ b/part3intro/toolchaintechnotes.xml @@ -158,8 +158,10 @@ 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. Without an emulation layer, you cannot run an executable for - the server on the mobile phone or vice versa. So the + 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 system field is separated into kernel and os fields to designate these systems unambiguously. For our example, the Android system is designated aarch64-unknown-linux-android, From 543c94cb9cf7e27e4817960a94e1429130799f27 Mon Sep 17 00:00:00 2001 From: Xi Ruoyao Date: Fri, 30 Sep 2022 17:03:08 +0800 Subject: [PATCH 3/3] libstdc++ "stage 3" is not rebuilt for the same reason as "stage 2" I'm pretty sure "stage 2" libstdc++ (installed in ch6) is already fully featured. The reason to rebuild the stage 3 libstdc++ (or entire stage 3 gcc) is same as the reason to rebuild every packages in multiple chapters: to "settle down" it. Merge the content of https://www.linuxfromscratch.org/lfs/faq.html#rebuild-ch8 into the book as an explanation. --- general.ent | 3 +++ part3intro/toolchaintechnotes.xml | 19 +++++++++++++++++-- 2 files changed, 20 insertions(+), 2 deletions(-) diff --git a/general.ent b/general.ent index 1328f7c7c..81a7b51dc 100644 --- a/general.ent +++ b/general.ent @@ -123,6 +123,9 @@ lfs"> /etc/fstab"> /boot"> +"> +"> +"> %packages-entities; diff --git a/part3intro/toolchaintechnotes.xml b/part3intro/toolchaintechnotes.xml index a6206bb91..16b6aafd2 100644 --- a/part3intro/toolchaintechnotes.xml +++ b/part3intro/toolchaintechnotes.xml @@ -256,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). + compiler. So we have to re-build libstdc++ later as a part of + gcc stage 2. + + In &ch-final; (or stage 3), 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.