Translation Source string Target string
Linux From Scratch/part3intro_toolchaintechnotes — Chinese (Simplified Han script)
This section explains some of the rationale and technical details behind the overall build method. Don't try to immediately understand everything in this section. Most of this information will be clearer after performing an actual build. Come back and re-read this chapter at any time during the build process.
本节综合地解释构建方法中的逻辑和技术细节。您现在并不需要立刻理解本节的所有内容，在实际进行构建的过程中，可以更清晰地理解本节的信息。在整个构建过程中，您随时可以回来翻阅本节。
Linux From Scratch/part3intro_toolchaintechnotes — Chinese (Simplified Han script)
The overall goal of <xref linkend="chapter-cross-tools"/> and <xref linkend="chapter-temporary-tools"/> is to produce a temporary area containing a set of tools that are known to be good, and that are isolated from the host system. By using the <command>chroot</command> command, the compilations in the remaining chapters will be isolated within that environment, ensuring a clean, trouble-free build of the target LFS system. The build process has been designed to minimize the risks for new readers, and to provide the most educational value at the same time.
<xref linkend="chapter-cross-tools"/>和<xref linkend="chapter-temporary-tools"/>的总目标是构造一个临时环境，它包含一组可靠的，能够与宿主系统完全分离的工具。这样，通过使用 <command>chroot</command> 命令，其余各章中执行的命令就被限制在这个临时环境中。这确保我们能够干净、顺利地构建 LFS 系统。整个构建过程被精心设计，以尽量降低新读者可能面临的风险，同时提供尽可能多的教育价值。
Linux From Scratch/part3intro_toolchaintechnotes — Chinese (Simplified Han script)
This build process is based on <emphasis>cross-compilation</emphasis>. Cross-compilation is normally used to build a compiler and its associated toolchain for a machine different from the one that is used for the build. This is not strictly necessary for LFS, since the machine where the new system will run is the same as the one used for the build. But cross-compilation has one great advantage: anything that is cross-compiled cannot depend on the host environment.
构建过程是基于<emphasis>交叉编译</emphasis>过程的。交叉编译通常被用于为一台与本机完全不同的计算机构建编译器及其工具链。这对于 LFS 并不严格必要，因为新系统运行的机器就是构建它时使用的。但是，交叉编译拥有一项重要优势，即任何交叉编译产生的程序都不可能依赖于宿主环境。
Linux From Scratch/part3intro_toolchaintechnotes — Chinese (Simplified Han script)
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 than building LFS, unless you really understand what you are doing.
 
Linux From Scratch/part3intro_toolchaintechnotes — Chinese (Simplified Han script)
Cross-compilation involves some concepts that deserve a section of their own. Although this section may be omitted on a first reading, coming back to it later will help you gain a fuller understanding of the process.
交叉编译涉及一些概念，值得专门用一节讨论。尽管您可以在初次阅读时跳过本节，但强烈建议您之后回头阅读本节，以完全掌握构建过程。
Linux From Scratch/part3intro_toolchaintechnotes — Chinese (Simplified Han script)
Let us first define some terms used in this context.
首先我们定义讨论交叉编译时常用的术语：
Linux From Scratch/part3intro_toolchaintechnotes — Chinese (Simplified Han script)
The build
build
Linux From Scratch/part3intro_toolchaintechnotes — Chinese (Simplified Han script)
is the machine where we build programs. Note that this machine is also referred to as the <quote>host.</quote>
指构建程序时使用的机器。注意在某些其他章节，这台机器被称为<quote>host</quote>(宿主)。
Linux From Scratch/part3intro_toolchaintechnotes — Chinese (Simplified Han script)
The host
host
Linux From Scratch/part3intro_toolchaintechnotes — Chinese (Simplified Han script)
The target
target
Linux From Scratch/part3intro_toolchaintechnotes — Chinese (Simplified Han script)
is only used for compilers. It is the machine the compiler produces code for. It may be different from both the build and the host.
只有编译器使用这个术语。编译器为这台机器产生代码。它可能和 build 与 host 都不同。
Linux From Scratch/part3intro_toolchaintechnotes — Chinese (Simplified Han script)
As an example, let us imagine the following scenario (sometimes 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 want to produce code for a third, slow machine (C). We will build a compiler for machine C in three stages.
例如，我们考虑下列场景 (有时称为<quote>Canadian Cross</quote>)：我们仅在一台运行缓慢的机器上有编译器，称这台机器为 A，这个编译器为 ccA。我们还有一台运行较快的机器 (B)，但它没有安装编译器，而我们希望为另一台缓慢的机器 (C) 生成代码。如果要为 C 构建编译器，可以通过三个阶段完成：
Linux From Scratch/part3intro_toolchaintechnotes — Chinese (Simplified Han script)
Build cross-compiler cc1 using ccA on machine A.
在机器 A 上，使用 ccA 构建交叉编译器 cc1
Linux From Scratch/part3intro_toolchaintechnotes — Chinese (Simplified Han script)
Build cross-compiler cc2 using cc1 on machine A.
在机器 A 上，使用 cc1 构建交叉编译器 cc2
Linux From Scratch/part3intro_toolchaintechnotes — Chinese (Simplified Han script)
Build compiler ccC using cc2 on machine B.
在机器 B 上，使用 cc2 构建交叉编译器 ccC
Linux From Scratch/part3intro_toolchaintechnotes — Chinese (Simplified Han script)
Then, all the programs needed by machine C can be compiled using cc2 on the fast machine B. Note that unless B can run programs produced for C, there is no way to test the newly built programs until machine C itself is running. For example, to run a test suite on ccC, we may want to add a fourth stage:
这样，我们可以为机器 C 使用 cc2 在快速的机器 B 上构建所有其他程序。注意除非 B 能运行为 C 编译的程序，我们无法测试编译得到的程序，直到在 C 上运行它。例如，如果要测试 ccC，我们可以增加第四个阶段：
Linux From Scratch/part3intro_toolchaintechnotes — Chinese (Simplified Han script)
Rebuild and test ccC using ccC on machine C.
在机器 C 上，用 ccC 重新构建它本身，并测试
Linux From Scratch/part3intro_toolchaintechnotes — Chinese (Simplified Han script)
All the cross-compiled packages in this 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 often irrelevant, autoconf lets you omit it.
 
Linux From Scratch/part3intro_toolchaintechnotes — Chinese (Simplified Han script)
An astute reader may wonder why a <quote>triplet</quote> refers to a four component name. The 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 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, even though they are both running on the same type of CPU (ARM64) and using the same kernel (Linux).
 
Linux From Scratch/part3intro_toolchaintechnotes — Chinese (Simplified Han script)
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>.
 
Linux From Scratch/part3intro_toolchaintechnotes — Chinese (Simplified Han script)
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, 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 system it will be <emphasis>x86_64-pc-linux-gnu</emphasis>. On most Linux systems the even simpler <command>gcc -dumpmachine</command> command will give you similar information.
 
Linux From Scratch/part3intro_toolchaintechnotes — Chinese (Simplified Han script)
You should also be aware of the name of the platform's dynamic linker, often referred to as the dynamic loader (not to be confused with the standard linker <command>ld</command> that is part of binutils). The dynamic linker provided by package glibc finds and loads the shared libraries needed by a program, prepares the program to run, and then runs it. The name of the dynamic linker for a 32-bit Intel machine is <filename class="libraryfile">ld-linux.so.2</filename>; it's <filename class="libraryfile">ld-linux-x86-64.so.2</filename> on 64-bit systems. A sure-fire way to determine the name of the dynamic linker is to inspect a random binary from the host system by running: <userinput>readelf -l &lt;name of binary&gt; | grep interpreter</userinput> and noting the output. The authoritative reference covering all platforms is in <ulink url='https://sourceware.org/glibc/wiki/ABIList'>a Glibc wiki page</ulink>.
另外注意平台的动态链接器的名称，它又被称为动态加载器 (不要和 Binutils 中的普通链接器 <command>ld</command> 混淆)。动态链接器由 Glibc 提供，它寻找并加载程序所需的共享库，为程序运行做好准备，然后运行程序。在 32 位 Intel 机器上动态链接器的名称是 <filename class="libraryfile">ld-linux.so.2</filename> (在 64 位系统上是 <filename class="libraryfile">ld-linux-x86-64.so.2</filename>)。一个确定动态链接器名称的准确方法是从宿主系统找一个二进制可执行文件，然后执行：<userinput>readelf -l &lt;二进制文件名&gt; | grep interpreter</userinput> 并观察输出。包含所有平台的权威参考可以在 Glibc 源码树根目录的 <filename>shlib-versions</filename> 文件中找到。
Linux From Scratch/part3intro_toolchaintechnotes — Chinese (Simplified Han script)
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 ensures that none of the other programs built in <xref linkend="chapter-temporary-tools"/> can link to libraries on the build machine. Only two stages are mandatory, plus one more for tests.
为了将本机伪装成交叉编译目标机器，我们在 <envar>LFS_TGT</envar> 变量中，对宿主系统三元组的 &quot;vendor&quot; 域进行修改。我们还会在构建交叉链接器和交叉编译器时使用 <parameter>--with-sysroot</parameter> 选项，指定查找所需的 host 系统文件的位置。这保证在<xref linkend="chapter-temporary-tools"/>中的其他程序在构建时不会链接到宿主 (build) 系统的库。前两个阶段是必要的，第三个阶段可以用于测试：
Linux From Scratch/part3intro_toolchaintechnotes — Chinese (Simplified Han script)
Build cross-compiler cc1 using cc-pc on pc.
在 pc 上使用 cc-pc 构建交叉编译器 cc1
Linux From Scratch/part3intro_toolchaintechnotes — Chinese (Simplified Han script)
Build compiler cc-lfs using cc1 on pc.
在 pc 上使用 cc1 构建 cc-lfs
Linux From Scratch/part3intro_toolchaintechnotes — Chinese (Simplified Han script)
Rebuild and test cc-lfs using cc-lfs on lfs.
在 lfs 上使用 cc-lfs 重新构建并测试它本身
Linux From Scratch/part3intro_toolchaintechnotes — Chinese (Simplified Han script)
In the preceding table, <quote>on pc</quote> means the commands are run on a machine using the already installed distribution. <quote>On lfs</quote> means the commands are run in a chrooted environment.
在上表中，<quote>在 pc 上</quote> 意味着命令在已经安装好的发行版中执行。<quote>在 lfs 上</quote> 意味着命令在 chroot 环境中执行。
Linux From Scratch/part3intro_toolchaintechnotes — Chinese (Simplified Han script)
This is not yet the end of the story. The C language is not merely a compiler; it 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 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 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, lacking some functionalities such as threads and exception handling, and then to build glibc using this degraded compiler (glibc itself is not degraded), and also to build libstdc++. This last library will lack some of the functionality of libgcc.
现在，关于交叉编译，还有更多要处理的问题：C 语言并不仅仅由一个编译器实现，它还规定了一个标准库。在本书中，我们使用 GNU C 运行库，即 glibc。它必须为 lfs 目标机器使用交叉编译器 cc1 编译。但是，编译器本身使用一个库，实现汇编指令集并不支持的一些复杂指令。这个内部库称为 libgcc，它必须链接到 glibc 库才能实现完整功能！另外，C++ 标准库 (libstdc++) 也必须链接到 glibc。为了解决这个”先有鸡还是先有蛋“的问题，只能先构建一个降级的 cc1，它的 libgcc 缺失线程和异常等功能，再用这个降级的编译器构建 glibc (这不会导致 glibc 缺失功能)，再构建 libstdc++。但是这种方法构建的 libstdc++ 和 libgcc 一样，会缺失一些功能。
Linux From Scratch/part3intro_toolchaintechnotes — Chinese (Simplified Han script)
The upshot of the preceding paragraph is that cc1 is unable to build a fully functional libstdc++ with the degraded libgcc, but cc1 is the only compiler available for building the C/C++ libraries during stage 2. There are two reasons we don't immediately use the compiler built in stage 2, cc-lfs, to build those libraries.
讨论还没有结束：上面一段的结论是 cc1 无法构建功能完整的 libstdc++，但这是我们在阶段 2 构建 C/C++ 库时唯一可用的编译器！当然，在阶段 2 中构建的编译器 cc-lfs 将会可以构建这些库，但是 (1) GCC 构建系统不知道这个编译器在 pc 上可以使用，而且 (2) 它是一个本地编译器，因此在 pc 上使用它可能产生链接到 pc (宿主系统) 库的风险。因此我们必须在进入 chroot 后再次构建 libstdc++。
Linux From Scratch/part3intro_toolchaintechnotes — Chinese (Simplified Han script)
Generally speaking, cc-lfs cannot run on pc (the host system). Even though the triplets for pc and lfs are compatible with each other, an executable for lfs must depend on glibc-&glibc-version;; the host distro may utilize either a different implementation of libc (for example, musl), or a previous release of glibc (for example, glibc-2.13).
 
Linux From Scratch/part3intro_toolchaintechnotes — Chinese (Simplified Han script)
Even if cc-lfs can run on pc, using it on pc would create a risk of linking to the pc libraries, since cc-lfs is a native compiler.
 
Linux From Scratch/part3intro_toolchaintechnotes — Chinese (Simplified Han script)
So when we build gcc stage 2, we instruct the building system to rebuild libgcc and libstdc++ with cc1, but we link libstdc++ to the newly rebuilt libgcc instead of the old, degraded build. This makes the rebuilt libstdc++ fully functional.
 
Linux From Scratch/part3intro_toolchaintechnotes — Chinese (Simplified Han script)
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 an LFS package on a completed LFS system, the reinstalled content of the package should be the same as the content of the same package when first installed in &ch-final;. The temporary packages installed in &ch-tmp-cross; or &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 to run the test suites.
 
Linux From Scratch/part3intro_toolchaintechnotes — Chinese (Simplified Han script)
Other Procedural Details
构建过程的其他细节
Linux From Scratch/part3intro_toolchaintechnotes — Chinese (Simplified Han script)
Binutils is installed first because the <command>configure</command> runs of both gcc and glibc perform various feature tests on the assembler and linker to determine which software features to enable or disable. This is more important than one might realize at first. An incorrectly configured gcc or glibc can result in a subtly broken toolchain, where the impact of such breakage might not show up until near the end of the build of an entire distribution. A test suite failure will usually highlight this error before too much additional work is performed.
我们首先安装 Binutils。这是由于 GCC 和 Glibc 的 <command>configure</command> 脚本首先测试汇编器和链接器的一些特性，以决定启用或禁用一些软件特性。初看起来这并不重要，但没有正确配置的 GCC 或者 Glibc 可以导致工具链中潜伏的故障。这些故障可能到整个构建过程快要结束时才突然爆发，不过在花费大量无用功之前，测试套件的失败可以将这类错误凸显出来。
Linux From Scratch/part3intro_toolchaintechnotes — Chinese (Simplified Han script)
Binutils installs its assembler and linker in two locations, <filename class="directory">$LFS/tools/bin</filename> and <filename class="directory">$LFS/tools/$LFS_TGT/bin</filename>. The tools in one location are hard linked to the other. An important facet of the linker is its library search order. Detailed information can be obtained from <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 logged in as user <systemitem class="username">lfs</systemitem>. If you come back to this page later, replace <command>$LFS_TGT-ld</command> with <command>ld</command>).
Binutils 将汇编器和链接器安装在两个位置，一个是 <filename class="directory">$LFS/tools/bin</filename>，另一个是 <filename class="directory">$LFS/tools/$LFS_TGT/bin</filename>。这两个位置中的工具互为硬链接。链接器的一项重要属性是它搜索库的顺序，通过向 <command>ld</command> 命令加入 <parameter>--verbose</parameter> 参数，可以得到关于搜索路径的详细信息。例如，<command>ld --verbose | grep SEARCH</command> 会输出当前的搜索路径及其顺序。此外，通过编译一个样品 (dummy) 程序并向链接器 <command>ld</command> 传递 <parameter>--verbose</parameter> 参数，可以知道哪些文件被链接。例如，<command>gcc dummy.c -Wl,--verbose 2&gt;&amp;1 | grep succeeded</command> 将显示所有在链接过程中被成功打开的文件。
Linux From Scratch/part3intro_toolchaintechnotes — Chinese (Simplified Han script)
The next package installed is gcc. An example of what can be seen during its run of <command>configure</command> is:
下一步安装 GCC。在执行它的 <command>configure</command> 脚本时，您会看到类似下面这样的输出：
Linux From Scratch/part3intro_toolchaintechnotes — Chinese (Simplified Han script)
This is important for the reasons mentioned above. It also demonstrates that gcc's configure script does not search the PATH directories to find which tools to use. However, during the actual 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> prefix if coming back to this later.)
基于我们上面论述的原因，这些输出非常重要。这说明 GCC 的配置脚本没有在 PATH 变量指定的目录中搜索工具。然而，在 <command>gcc</command> 的实际运行中，未必会使用同样的搜索路径。为了查询 <command>gcc</command> 会使用哪个链接器，需要执行以下命令：<command>$LFS_TGT-gcc -print-prog-name=ld</command>。
Linux From Scratch/part3intro_toolchaintechnotes — Chinese (Simplified Han script)
Detailed information can be obtained from <command>gcc</command> by passing it the <parameter>-v</parameter> command line option while compiling a program. For example, <command>$LFS_TGT-gcc -v <replaceable>example.c</replaceable></command> (or without <command> $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.
通过向 <command>gcc</command> 传递 <parameter>-v</parameter> 参数，可以知道在编译样品程序时发生的细节。例如，<command>gcc -v dummy.c</command> 会输出预处理、编译和汇编阶段中的详细信息，包括 <command>gcc</command> 的包含文件搜索路径和顺序。
Linux From Scratch/part3intro_toolchaintechnotes — Chinese (Simplified Han script)
Next up: sanitized Linux API headers. These allow the standard C library (glibc) to interface with features that the Linux kernel will provide.
下一步安装“净化的” (sanitized) Linux API 头文件。这允许 C 标准库 (Glibc) 与 Linux 内核提供的各种特性交互。
Linux From Scratch/part3intro_toolchaintechnotes — Chinese (Simplified Han script)
Next comes glibc. The most important considerations for building glibc are the compiler, binary tools, and kernel headers. The compiler and binary tools are generally not an issue since glibc will always those relating to the <parameter>--host</parameter> parameter passed to its configure script; e.g., in our case, the compiler will be <command>$LFS_TGT-gcc</command> and the <command>readelf</command> tool will be <command>$LFS_TGT-readelf</command>. The kernel headers can be a bit more complicated. Therefore, we take no risks and use the available configure switch to enforce the correct selection. After the run of <command>configure</command>, check the contents of the <filename>config.make</filename> file in the <filename class="directory">build</filename> directory for all important details. These items highlight an important aspect of the glibc package&mdash;it is very self-sufficient in terms of its build machinery, and generally does not rely on toolchain defaults.
下一步安装 Glibc。在构建 Glibc 时需要着重考虑编译器，二进制工具，以及内核头文件。编译器一般不成问题，Glibc 总是使用传递给配置脚本的 <parameter>--host</parameter> 参数相关的编译器。例如，在我们的例子中，使用的编译器是 <command>$LFS_TGT-gcc</command>。但二进制工具和内核头文件的问题比较复杂。安全起见，我们使用配置脚本提供的开关，保证正确的选择。在 <command>configure</command> 脚本运行完成后，可以检查 <filename>build</filename> 目录中的 <filename>config.make</filename> 文件，了解全部重要的细节。注意参数 <parameter>CC="$LFS_TGT-gcc"</parameter> (其中 <envar>$LFS_TGT</envar> 会被展开) 控制构建系统使用正确的二进制工具，而参数 <parameter>-nostdinc</parameter> 和 <parameter>-isystem</parameter> 控制编译器的包含文件搜索路径。这些事项凸显了 Glibc 软件包的一个重要性质 —— 它的构建机制是相当自给自足的，通常不依赖于工具链默认值。
Linux From Scratch/part3intro_toolchaintechnotes — Chinese (Simplified Han script)
As mentioned above, the standard C++ library is compiled next, followed in <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 in the LFS filesystem.
正如前文所述，接下来构建 C++ 标准库，然后是<xref linkend="chapter-temporary-tools"/>中那些需要自身才能构建的程序后。在安装这些软件包时使用 <envar>DESTDIR</envar> 变量，将它安装到 LFS 文件系统中。
Linux From Scratch/part3intro_toolchaintechnotes — Chinese (Simplified Han script)
At the end of <xref linkend="chapter-temporary-tools"/> the native LFS compiler is installed. First binutils-pass2 is built, in the same <envar>DESTDIR</envar> directory as the other programs, then the second pass of gcc is constructed, omitting some non-critical libraries. Due to some weird logic in gcc's configure script, <envar>CC_FOR_TARGET</envar> ends up as <command>cc</command> when the host is the same as the target, but different from the build system. This is why <parameter>CC_FOR_TARGET=$LFS_TGT-gcc</parameter> is declared explicitly as one of the configuration options.
在<xref linkend="chapter-temporary-tools"/>一节的末尾，构建 lfs 本地编译器。首先使用和其他程序相同的 <envar>DESTDIR</envar> 第二次构建 binutils，然后第二次构建 GCC，构建时忽略 libstdc++ 和其他不重要的库。由于 GCC 配置脚本的一些奇怪逻辑，<envar>CC_FOR_TARGET</envar> 变量在 host 系统和 target 相同，但与 build 不同时，被设定为 <command>cc</command>。因此我们必须显式地在配置选项中指定 <parameter>CC_FOR_TARGET=$LFS_TGT-gcc</parameter>。
Linux From Scratch/part3intro_toolchaintechnotes — Chinese (Simplified Han script)
Upon entering the chroot environment in <xref linkend="chapter-chroot-temporary-tools"/>, the temporary installations of programs needed for the proper operation of the toolchain are performed. From this point onwards, the 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 installed.
在<xref linkend="chapter-chroot-temporary-tools"/>中，进入 chroot 环境后，首先安装 libstdc++。之后临时性地安装工具链的正常工作所必须的程序。还要构建测试其他程序时必须的程序。此后，核心工具链成为自包含的本地工具链。在<xref linkend="chapter-building-system"/>中，构建、测试并最后一次安装所有软件包，它们组成功能完整的系统。