Bläddra i källkod

chapter05: translate toolchain technology notes

Xi Ruoyao 7 år sedan
förälder
incheckning
10f385415b
1 ändrade filer med 162 tillägg och 44 borttagningar
  1. 162 44
      chapter05/toolchaintechnotes.xml

+ 162 - 44
chapter05/toolchaintechnotes.xml

@@ -1,4 +1,4 @@
-<?xml version="1.0" encoding="ISO-8859-1"?>
+<?xml version="1.0" encoding="UTF-8"?>
 <!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
   "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
   <!ENTITY % general-entities SYSTEM "../general.ent">
@@ -8,33 +8,51 @@
 <sect1 id="ch-tools-toolchaintechnotes">
   <?dbhtml filename="toolchaintechnotes.html"?>
 
-  <title>Toolchain Technical Notes</title>
+  <title>工具链技术说明</title>
 
-  <para>This section explains some of the rationale and technical details
+  <!--para>This section explains some of the rationale and technical details
   behind the overall build method. It is not essential to immediately
   understand everything in this section. Most of this information will be
   clearer after performing an actual build. This section can be referred
-  to at any time during the process.</para>
+  to at any time during the process.</para-->
+  <para>本节综合地解释构建方法中的逻辑和技术细节。
+	  您现在并不需要立刻理解本节的所有内容,在实际进行构建的过程中,
+	  可以更清晰地理解本节的信息。在整个构建过程中,您随时可以回来翻阅本节。
+  </para>
 
-  <para>The overall goal of <xref linkend="chapter-temporary-tools"/> is to
+  <!--para>The overall goal of <xref linkend="chapter-temporary-tools"/> is to
   produce a temporary area that contains a known-good set of tools that can be
   isolated from the host system. By using <command>chroot</command>, the
   commands in the remaining chapters will be contained 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.</para>
+  the most educational value at the same time.</para-->
+  <para>
+  	  <xref linkend="chapter-temporary-tools"/>
+      的总目标是构造一个临时环境,它包含一组可靠的,
+      能够与宿主系统完全分离的工具。这样,通过使用 <command>chroot</command>
+      命令,其余各章中执行的命令就被限制在这个临时环境中。
+      这确保我们能够干净、顺利地构建 LFS 系统。整个构建过程被精心设计,
+	  以尽量降低新读者可能面临的风险,同时提供最多的教育价值。</para>
 
   <note>
-    <para>Before continuing, be aware of the name of the working platform,
+    <!--para>Before continuing, be aware of the name of the working platform,
     often referred to as the target triplet. A simple way to determine the
     name of the target 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
     output will be <emphasis>i686-pc-linux-gnu</emphasis>. On a 64-bit
-    system it will be <emphasis>x86_64-pc-linux-gnu</emphasis>.</para>
+    system it will be <emphasis>x86_64-pc-linux-gnu</emphasis>.</para-->
+    <para>在继续阅读之前,请注意往往被称为目标三元组的工作平台名称。
+		获得它的一种简单方法是运行许多软件包附带的
+		<command>config.guess</command> 脚本。解压缩 Binutils 源码,
+		然后运行脚本:<userinput>./config.guess</userinput>,观察输出。
+		例如,对于 32 位 Intel 处理器,输出应该是
+		<emphasis>i686-pc-linux-gnu</emphasis>,而对于 64 位系统输出应该是
+		<emphasis>x86_64-pc-linux-gnu</emphasis>。</para>
 
-    <para>Also be aware of the name of the platform's dynamic linker, often
+    <!--para>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 Glibc finds and loads the shared libraries needed by a program,
@@ -47,86 +65,155 @@
     &lt;name of binary&gt; | grep interpreter</userinput> and noting the
     output. The authoritative reference covering all platforms is in the
     <filename>shlib-versions</filename> file in the root of the Glibc source
-    tree.</para>
+    tree.</para-->
+    <para>另外注意平台的动态链接器的名称,它又被称为动态加载器
+		(不要和 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> 文件中找到。</para>
   </note>
 
-  <para>Some key technical points of how the <xref
-  linkend="chapter-temporary-tools"/> build method works:</para>
+  <!--para>Some key technical points of how the <xref
+  linkend="chapter-temporary-tools"/> build method works:</para-->
+  <para><xref linkend="chapter-temporary-tools"/> 中构建方法的技术重点在于:
+  </para>
 
   <itemizedlist>
     <listitem>
-      <para>Slightly adjusting the name of the working platform, by changing the
+      <!--para>Slightly adjusting the name of the working platform, by changing the
       &quot;vendor&quot; field target triplet by way of the
       <envar>LFS_TGT</envar> variable, ensures that the first build of Binutils
       and GCC produces a compatible cross-linker and cross-compiler. Instead of
       producing binaries for another architecture, the cross-linker and
       cross-compiler will produce binaries compatible with the current
-      hardware.</para>
+      hardware.</para-->
+      <para>轻微调整工作平台的名称,将目标三元组中的 <quote>供应商</quote>
+		  (vendor) 字段修改,得到 <envar>LFS_TGT</envar> 中的三元组。
+		  这保证我们第一次构建 Binutils 和 GCC 时,
+		  能够产生与宿主系统兼容的交叉链接器和交叉编译器。
+		  它们不为其他架构生成二进制代码,
+		  而是生成与当前硬件兼容的二进制代码。</para>
     </listitem>
     <listitem>
-      <para> The temporary libraries are cross-compiled.  Because a
+      <!--para> The temporary libraries are cross-compiled.  Because a
       cross-compiler by its nature cannot rely on anything from its host
       system, this method removes potential contamination of the target
       system by lessening the chance of headers or libraries from the host
       being incorporated into the new tools.  Cross-compilation also allows for
       the possibility of building both 32-bit and 64-bit libraries on 64-bit
-      capable hardware.</para>
+      capable hardware.</para-->
+      <para>交叉编译临时环境中的库。
+		  由于交叉编译器从本质上不可能依赖于宿主环境中的任何东西,
+		  我们可以降低宿主环境中头文件或库被嵌入新编译的工具的概率,
+		  从而防止新编译的系统被污染。另外,交叉编译使得我们可能在
+		  64 位硬件上同时编译出 32 位和 64 位的库。</para>
     </listitem>
     <listitem>
-    <para>Careful manipulation of the GCC source tells the compiler which target
-    dynamic linker will be used.</para>
+    <!--para>Careful manipulation of the GCC source tells the compiler which target
+    dynamic linker will be used.</para-->
+    <para>小心地修改 GCC 源代码,
+		从而使得编译器使用我们指定的目标系统动态链接器。</para>
     </listitem>
   </itemizedlist>
 
-  <para>Binutils is installed first because the <command>configure</command>
+  <!--para>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 first realize. 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.</para>
+  before too much additional work is performed.</para-->
+  <para>我们首先安装 Binutils 。这是由于 GCC 和 Glibc 的
+	  <command>configure</command> 脚本首先测试汇编器和链接器的一些特性,
+	  以决定启用或禁用一些软件特性。初看起来这并不重要,
+	  但没有正确配置的 GCC 或者 Glibc 可以导致工具链中潜伏的故障。
+	  这些故障可能到整个构建过程快要结束时才突然爆发,
+	  不过在花费大量无用功之前,测试套件的失败可以将这类错误凸显出来。
+  </para>
 
-  <para>Binutils installs its assembler and linker in two locations,
+  <!--para>Binutils installs its assembler and linker in two locations,
   <filename class="directory">/tools/bin</filename> and <filename
   class="directory">/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, an <userinput>ld --verbose | grep SEARCH</userinput>
+  <command>ld</command> by passing it the <parameter>verbose</parameter>
+  flag. For example, an <userinput>ld verbose | grep SEARCH</userinput>
   will illustrate the current search paths and their order. It shows which
   files are linked by <command>ld</command> by compiling a dummy program and
-  passing the <parameter>--verbose</parameter> switch to the linker. For example,
-  <userinput>gcc dummy.c -Wl,--verbose 2&gt;&amp;1 | grep succeeded</userinput>
-  will show all the files successfully opened during the linking.</para>
+  passing the <parameter>verbose</parameter> switch to the linker. For example,
+  <userinput>gcc dummy.c -Wl,verbose 2&gt;&amp;1 | grep succeeded</userinput>
+  will show all the files successfully opened during the linking.</para-->
+  <para>Binutils 将汇编器和链接器安装在两个位置,一个是
+	  <filename class="directory">/tools/bin</filename>,
+	  另一个是 <filename class="directory">/tools/$LFS_TGT/bin</filename>。
+	  这两个位置中的工具互为硬链接。链接器的一个重要方面是它搜索库的顺序,
+	  通过向 <command>ld</command> 命令加入 <parameter>--verbose</parameter>
+	  参数,可以得到关于搜索路径的详细信息。例如,
+	  <userinput>ld --verbose | grep SEARCH</userinput>
+	  会输出当前的搜索路径及其顺序。此外,通过编译一个样品 (dummy)
+	  程序并向链接器传递 <parameter>--verbose</parameter> 参数,
+	  可以知道哪些文件被链接。例如,
+	  <userinput>gcc dummy.c -Wl,--verbose 2&gt;&amp;1 | grep succeeded
+  </userinput> 将显示所有在链接过程中被成功打开的文件。</para>
 
-  <para>The next package installed is GCC. An example of what can be
-  seen during its run of <command>configure</command> is:</para>
+  <!--para>The next package installed is GCC. An example of what can be
+  seen during its run of <command>configure</command> is:</para-->
+  <para>下一步安装 GCC。在执行它的 <command>configure</command> 脚本时,
+	  您会看到类似下面这样的输出:</para>
 
 <screen><computeroutput>checking what assembler to use... /tools/i686-lfs-linux-gnu/bin/as
 checking what linker to use... /tools/i686-lfs-linux-gnu/bin/ld</computeroutput></screen>
 
-  <para>This is important for the reasons mentioned above. It also demonstrates
+  <!--para>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:
-  <userinput>gcc -print-prog-name=ld</userinput>.</para>
+  <userinput>gcc -print-prog-name=ld</userinput>.</para-->
+  <para>基于我们上面论述的原因,这些输出非常重要。
+	  这说明 GCC 的配置脚本没有在 PATH 变量指定的目录中搜索工具。
+	  然而,在 <command>gcc</command> 的实际运行中,
+	  未必会使用同样的搜索路径。为了查询 <command>gcc</command>
+	  会使用哪个链接器,需要执行下列命令:
+	  <userinput>gcc -print-prog-name=ld</userinput>。</para>
 
-  <para>Detailed information can be obtained from <command>gcc</command> by
+  <!--para>Detailed information can be obtained from <command>gcc</command> by
   passing it the <parameter>-v</parameter> command line option while compiling
   a dummy program. For example, <userinput>gcc -v dummy.c</userinput> will show
   detailed information about the preprocessor, compilation, and assembly stages,
-  including <command>gcc</command>'s included search paths and their order.</para>
+  including <command>gcc</command>'s included search paths and their order.</para-->
+  <para> 通过向 <command>gcc</command> 传递 <parameter>-v</parameter>
+	  参数,可以知道在编译样品程序时发生的细节。例如,
+	  <userinput>gcc -v dummy.c</userinput>
+	  会输出预处理、编译和汇编阶段中的详细信息,包括 <command>gcc</command>
+	  的包含文件搜索路径和顺序。</para>
 
-  <para>Next installed are sanitized Linux API headers. These allow the standard
+  <!--para>Next installed are sanitized Linux API headers. These allow the standard
   C library (Glibc) to interface with features that the Linux kernel will
-  provide.</para>
+  provide.</para-->
+  <para>下一步安装<quote>净化的</quote> (sanitized) Linux API 头文件。
+	  这允许 C 标准库 (Glibc) 与 Linux 内核提供的各种特性交互。</para>
+  <note><title>译注</title>
+	  <para>关于<quote>净化的</quote>一词的含义,见科普文章
+		  <ulink url="http://www.jinbuguo.com/kernel/header_story.html"/>。
+	  </para>
+  </note>
 
-  <para>The next package installed is Glibc. The most important considerations
+  <!--para>The next package installed is 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
+  relating to the <parameter>host</parameter> parameter passed to its
   configure script; e.g. in our case, the compiler will be
   <command>i686-lfs-linux-gnu-gcc</command>. The binary tools and kernel
   headers can be a bit more complicated. Therefore, take no risks and use the
@@ -139,13 +226,32 @@ checking what linker to use... /tools/i686-lfs-linux-gnu/bin/ld</computeroutput>
   <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 and
-  generally does not rely on toolchain defaults.</para>
+  generally does not rely on toolchain defaults.</para-->
+  <para>下一步安装 Glibc 。在构建 Glibc 时最重要的考虑是编译器、二进制工具
+	  和内核头文件。编译器一般不成问题, Glibc 总是使用传递给配置脚本的
+	  <parameter>--host</parameter> 参数相关的编译器。
+	  例如,在我们的例子中,使用的编译器是
+	  <command>i686-lfs-linux-gnu-gcc</command>。
+	  但二进制工具和内核头文件的问题比较复杂,安全起见,
+	  我们使用配置脚本提供的开关,保证正确的选择。
+	  在 <command>configure</command> 脚本运行完成后,可以检查
+	  <filename class="directory">glibc-build</filename> 目录中的
+	  <filename>config.make</filename> 文件,了解全部重要的细节。
+	  注意参数 <parameter>CC=i686-lfs-linux-gnu-gcc</parameter>
+	  控制构建系统使用正确的二进制工具,而参数
+	  <parameter>-nostdinc</parameter> 和
+	  <parameter>-isystem</parameter> 控制编译器的头文件搜索路径。
+	  这些事项凸显了 Glibc 软件包的一个重要性质 —— 
+	  它的构建机制是相当自给自足的,不依赖于工具链默认值。</para>
 
-  <para>During the second pass of Binutils, we are able to utilize the
-  <parameter>--with-lib-path</parameter> configure switch to control
-  <command>ld</command>'s library search path.</para>
+  <!--para>During the second pass of Binutils, we are able to utilize the
+  <parameter>with-lib-path</parameter> configure switch to control
+  <command>ld</command>'s library search path.</para-->
+  <para>在第二次构建 Binutils 时,我们在配置时使用开关
+	  <parameter>--with-lib-path</parameter> 来控制 <command>ld</command>
+	  的库文件搜索路径。</para>
 
-  <para>For the second pass of GCC, its sources also need to be modified to
+  <!--para>For the second pass of GCC, its sources also need to be modified to
   tell GCC to use the new dynamic linker. Failure to do so will result in the
   GCC programs themselves having the name of the dynamic linker from the host
   system's <filename class="directory">/lib</filename> directory embedded into
@@ -153,14 +259,26 @@ checking what linker to use... /tools/i686-lfs-linux-gnu/bin/ld</computeroutput>
   point onwards, the core toolchain is self-contained and self-hosted. The
   remainder of the <xref linkend="chapter-temporary-tools"/> packages all build
   against the new Glibc in <filename
-  class="directory">/tools</filename>.</para>
+  class="directory">/tools</filename>.</para-->
+  <para>在第二次构建 GCC 时,需要修改其源码,使 GCC 使用新的动态链接器。
+	  如果不这么做,GCC 程序中就会嵌入宿主
+	  <filename class="directory">/lib</filename> 目录中的动态链接器名称,
+	  从而破坏我们脱离宿主环境的目标。之后,核心工具链就是自包含、
+	  不依赖宿主的。<xref linkend="chapter-temporary-tools"/>
+	  中的其他软件包都将在 <filename class="directory">/tools</filename>
+	  中新的 Glibc 基础上构建。</para>
 
-  <para>Upon entering the chroot environment in <xref
+  <!--para>Upon entering the chroot environment in <xref
   linkend="chapter-building-system"/>, the first major package to be
   installed is Glibc, due to its self-sufficient nature mentioned above.
   Once this Glibc is installed into <filename
   class="directory">/usr</filename>, we will perform a quick changeover of the
   toolchain defaults, and then proceed in building the rest of the target
-  LFS system.</para>
+  LFS system.</para-->
+  <para>在进入 <xref linkend="chapter-building-system"/> 中的 chroot
+	  环境后,由于我们之前提到的自给性质,在全部重要软件包中首先安装 Glibc。
+	  一旦 Glibc 被安装在 <filename class="directory">/usr</filename>
+	  目录中,我们将会简便地修改工具链默认值,然后继续构建目标 LFS
+	  系统的剩余部分。</para>
 
 </sect1>