Home
+ "Linux From Scratch - Version 8.0-systemd ">主页
- 4.5. About
- SBUs
+ 4.5. 关于时间单位 SBU
- Many people would like to know beforehand approximately how long it
- takes to compile and install each package. Because Linux From Scratch
- can be built on many different systems, it is impossible to provide
- accurate time estimates. The biggest package (Glibc) will take
- approximately 20 minutes on the fastest systems, but could take up to
- three days on slower systems! Instead of providing actual times, the
- Standard Build Unit (SBU) measure will be used instead.
+ 大多数人都想知道编译和安装每个包大概需要多长时间，因为 Linux 系统可以安装在许多不同的硬件系统上，所以不可能提供准确的预估时间。比如说， 最大的软件包 (Glibc) 在最快的硬件系统上编译安装需要大约 20 分钟，但在较慢的硬件系统上可能需要长达三天的时间！在此不提供实际时间，而使用标准构建单位 (Standard Build Unit (SBU)) 来衡量。
- The SBU measure works as follows. The first package to be compiled
- from this book is Binutils in Chapter 5.
- The time it takes to compile this package is what will be referred to
- as the Standard Build Unit or SBU. All other compile times will be
- expressed relative to this time.
+ SBU 的测量原理如下：本书在 第五章 编译的第一个包是 Binutils ，编译这个包所需的时间被称为标准构建单位或 SBU 。所有其它包的编译时间都以此来表示。
- For example, consider a package whose compilation time is 4.5 SBUs.
- This means that if a system took 10 minutes to compile and install
- the first pass of Binutils, it will take approximately 45 minutes to build this
- example package. Fortunately, most build times are shorter than the
- one for Binutils.
+ 比如说，一个编译时间为 4.5 SBU 的包，这意味着如果在一个系统中花费了 10 分钟来编译和安装 Binutils ，则需要大约 45 分钟来构建此包。不过幸运的是，大多数包构建时间都要比 Binutils 所用的短。
- In general, SBUs are not entirely accurate because they depend on
- many factors, including the host system's version of GCC. They are
- provided here to give an estimate of how long it might take to
- install a package, but the numbers can vary by as much as dozens of
- minutes in some cases.
+ 一般来说， SBU 并不完全准确。构建包所耗时间依赖许多因素，包括主机系统的 GCC 版本。在这里只是用来估计构建某个包所耗时间，但在有些情况下，误差可能多达几十分钟。
- Note
+ 注意
- For many modern systems with multiple processors (or cores) the
- compilation time for a package can be reduced by performing a
- "parallel make" by either setting an environment variable or
- telling the make
- program how many processors are available. For instance, a Core2Duo
- can support two simultaneous processes with:
+ 对于具有多个物理处理器或者多内核处理器的现代硬件系统，可以通过设置环境变量来告知 make 程序有多少处理器核心可以用来并行处理，以减少包的编译时间。例如，酷睿 2 双核处理器 (Core2Duo) 可以同时支持两个进程：
export MAKEFLAGS='-j 2'
- or just building with:
+ 或者在编译时使用以下参数：
make -j2
- When multiple processors are used in this way, the SBU units in the
- book will vary even more than they normally would. In some cases,
- the make step will simply fail. Analyzing the output of the build
- process will also be more difficult because the lines of different
- processes will be interleaved. If you run into a problem with a
- build step, revert back to a single processor build to properly
- analyze the error messages.
+ 当使用多线程编译编译包时，一个包的构建时间通常比本书所说明的多。在某些情况下， make 步骤将会失败。多进程同时编译，生成的日志文件也会交错出现，这使得分析包编译过程输出的日志也更加困难。如果在构建软件包时遇到了问题，请返回到单核心处理器进行编译，以便分析错误信息。
Home
+ "Linux From Scratch - Version 8.0-systemd ">主页
4.6. About the Test Suites
+ "prepare-abouttestsuites">4.6. 关于测试套件
- Most packages provide a test suite. Running the test suite for a
- newly built package is a good idea because it can provide a
- “sanity
- check” indicating that everything compiled
- correctly. A test suite that passes its set of checks usually proves
- that the package is functioning as the developer intended. It does
- not, however, guarantee that the package is totally bug free.
+ 大多数软件包都提供了一个测试套件。运行相应的测试套件，可以提供 “正确性检查” ，即检查所有的编译是否正确。这个检查是验证该软件包是否正在以开发者的意图编译运行，并不能保证这个包没有 bug 。
- Some test suites are more important than others. For example, the
- test suites for the core toolchain packages—GCC, Binutils, and
- Glibc—are of the utmost importance due to their central role in
- a properly functioning system. The test suites for GCC and Glibc can
- take a very long time to complete, especially on slower hardware, but
- are strongly recommended.
+ 有些测试套件比其他测试套件更重要，比如说核心工具链软件包 GCC, Binutils, 和 Glibc 。这些软件包在系统中处于非常重要的地位，因此进行测试是非常有必要的。 GCC 和 Glibc 的测试可能要花很长时间才能完成，特别是硬件运行速度较慢时，但依旧强烈推荐进行测试。
- Note
+ 注意
- Experience has shown that there is little to be gained from running
- the test suites in Chapter
- 5. There can be no escaping the fact that the host system
- always exerts some influence on the tests in that chapter, often
- causing inexplicable failures. Because the tools built in Chapter
- 5 are temporary and eventually discarded, we do not recommend
- running the test suites in Chapter
- 5 for the average reader. The instructions for running those
- test suites are provided for the benefit of testers and developers,
- but they are strictly optional.
+ 经验表明，在 第五章 中运行测试套件几乎不能完全通过。主机系统总是会对测试产生一定得影响，这极有可能会导致一些莫名其妙的错误。因为 第五章构建的工具都是临时的，最后会被删掉，所以我们不建议普通读者在 第五章 运行测试套件。这些测试套件是为测试人员和开发者准备的，并不是必须要运行的。
-
+
- A common issue with running the test suites for Binutils and GCC is
- running out of pseudo terminals (PTYs). This can result in a high
- number of failing tests. This may happen for several reasons, but the
- most likely cause is that the host system does not have the
- devpts file system set up correctly.
- This issue is discussed in greater detail at http://www.linuxfromscratch.org/lfs/faq.html#no-ptys.
+ 运行 Binutils 和 GCC 的测试套件时，一个常见的问题是缺少伪终端 ( PTYs ) ，这有可能会导致在测试中出现大量的错误。有多种原因可能引起这种错误，最常见的原因是 “主机系统没能正确的配置 devpts 文件系统。关于这个问题在以下链接有更详细的讨论：
+
- Sometimes package test suites will fail, but for reasons which the
- developers are aware of and have deemed non-critical. Consult the
- logs located at http://www.linuxfromscratch.org/lfs/build-logs/8.0/
- to verify whether or not these failures are expected. This site is
- valid for all tests throughout this book.
+ 有时，测试套件会报告错误，但是开发者知道并认为这是非关键性问题。请参阅位于 http://www.linuxfromscratch.org/lfs/build-logs/8.0/ 的安装日志，以便验证这些错误是否是预期性的错误。此网站适用于本书中所有的测试。
Home
+ "Linux From Scratch - Version 8.0-systemd ">主页
4.3.
- Adding the LFS User
+ 添加 LFS 用户
- When logged in as user root, making a
- single mistake can damage or destroy a system. Therefore, we
- recommend building the packages in this chapter as an unprivileged
- user. You could use your own user name, but to make it easier to set
- up a clean working environment, create a new user called lfs as a member of a new group (also named
- lfs) and use this user during the
- installation process. As root, issue
- the following commands to add the new user:
+ 当使用 root 用户登陆时，一点小的错误就有可能破坏整个系统。因此，我们建议使用普通用户（非特权用户）构建这些软件包。你可以使用自己的用户名，但是为了更容易配置所需的工作环境，请创建一个名为 lfs 的新用户组，并创建名字同为 lfs 的新用户作为该用户组的成员，在安装过程中将会使用此用户。以 root 用户，键入以下命令：
groupadd lfs
@@ -68,7 +60,7 @@
- The meaning of the command line options:
+ 命令中选项的含义：
@@ -77,8 +69,7 @@
- This makes bash
- the default shell for user lfs.
+ 设置 bash 为 lfs 用户的默认 shell；
@@ -87,8 +78,7 @@
- This option adds user lfs to
- group lfs.
+ 将 lfs 用户添加到 lfs 用户组；
@@ -97,8 +87,7 @@
- This creates a home directory for lfs.
+ 为 lfs 用户创建 home 文件夹；
@@ -107,10 +96,7 @@
- This parameter prevents possible copying of files from a
- skeleton directory (default is /etc/skel) by changing the input location to
- the special null device.
+ 这个选项是通过将输入位置更改为 /dev/null, 从而阻止一些可能从默认的 /etc/skel 目录复制过来文件；
@@ -119,77 +105,63 @@
- This is the actual name for the created group and user.
+ 要创建用户的实际名称。
- To log in as lfs (as opposed to
- switching to user lfs when logged in
- as root, which does not require the
- lfs user to have a password), give
- lfs a password:
+ 为 lfs 用户设置密码：
passwd lfs
- Grant lfs full access to $LFS/tools by making lfs the directory owner:
+ 将 $LFS/tools 目录的所有者更改为 lfs 用户，使 lfs 用户获取完全访问权限：
chown -v lfs $LFS/tools
- If a separate working directory was created as suggested, give user
- lfs ownership of this directory:
+ 如果按照建议创建了单独的工作目录，请使用以下命令将该目录的拥有者更改为 lfs 用户：
chown -v lfs $LFS/sources
- Next, login as user lfs. This can be
- done via a virtual console, through a display manager, or with the
- following substitute user command:
+ 接下来以 lfs 用户登陆。可以通过虚拟控制台 (Virtual Console) 、显示管理器 (Display Manager) 或以下命令切换至 lfs 用户：
su - lfs
- The “-” instructs
- su to start a login
- shell as opposed to a non-login shell. The difference between these
- two types of shells can be found in detail in bash(1) and info
- bash.
+ “-” 是指完整切换到 lfs 用户环境，即 login shell ；如果不加 “-” 则表示只切换到其他用户，即 non-login shell 。这两种切换用户的区别可以在 bash(1) 和 info bash
+ 中找到。
- All programs compiled in Chapter 5
- will be installed under $LFS/tools to
- keep them separate from the programs compiled in Chapter
- 6. The programs compiled here are temporary tools and will not be
- a part of the final LFS system. By keeping these programs in a
- separate directory, they can easily be discarded later after their
- use. This also prevents these programs from ending up in the host
- production directories (easy to do by accident in Chapter
- 5).
+ 第五章 中编译的所有程序将安装在 $LFS/tools 文件夹下，以便和 第六章 中编译的程序分离开来。第五章编译的程序是临时工具，并非最终 LFS 系统的一部分，将这些编译后的临时工具保存在单独的目录，以便在使用完成后直接删除，同时也防止了和最终的 LFS 系统相互冲突。（第五章 的工作很容易出现一些意料不到的问题。）
- Create the required directory by running the following as
- root:
+ 使用 root 用户，通过以下命令来创建所需目录：
mkdir -v $LFS/tools
- The next step is to create a /tools
- symlink on the host system. This will point to the newly-created
- directory on the LFS partition. Run this command as root as well:
+ 下一步就是在系统中创建一个 /tools 文件夹的符号链接，该链接指向 LFS 分区上新创建的目录。使用 root 用户来执行此命令：
ln -sv $LFS/tools /
@@ -88,49 +69,39 @@
- Note
+ 注意
- The above command is correct. The ln command has a few syntactic
- variations, so be sure to check info
- coreutils ln and ln(1) before reporting what you may think is an
- error.
+ 上述命令是正确的。 ln 命令有一些语法上的变化，会检查 info coreutils ln 和 ln(1) 然后报告一个错误。
- The created symlink enables the toolchain to be compiled so that it
- always refers to /tools, meaning that
- the compiler, assembler, and linker will work both in Chapter 5 (when
- we are still using some tools from the host) and in the next (when we
- are “chrooted” to the LFS partition).
+ 创建符号链接，以便始终引用 /tools 目录下的程序编译工具链。这意味着第五章新编译的编译器、汇编器和连接器将都能在第五章（仍然使用一些主机系统提供的工具时）和第六章（ chroot 到 LFS 分区中时）中使用。
Home
+ "Linux From Scratch - Version 8.0-systemd ">首页
4.1.
- Introduction
+ 简介
- In this chapter, we will perform a few additional tasks to prepare
- for building the temporary system. We will create a directory in
- $LFS for the installation of the
- temporary tools, add an unprivileged user to reduce risk, and create
- an appropriate build environment for that user. We will also explain
- the unit of time we use to measure how long LFS packages take to
- build, or “SBUs”, and give some information about
- package test suites.
+ 在本章节中，我们将做一些额外的工作，用来准备构建临时系统。我们将在 $LFS 中创建一个用于安装临时工具的目录，添加一个非特权用户以降低风险，并且为该用户构建适当的编译环境。我们还将解释 “构建一个 $LFS 包所需时间” 的时间单位，称为 “SBU” ，并给一些关于测试套件的信息。
Home
+ "Linux From Scratch - Version 8.0-systemd ">主页
4.4. Setting Up the Environment
+ "ch-tools-settingenviron">4.4. 配置环境
- Set up a good working environment by creating two new startup files
- for the bash shell.
- While logged in as user lfs, issue
- the following command to create a new .bash_profile:
+ 通过为 bash shell 创建两个文件，来建立初始的环境变量。以 lfs 用户登陆，使用以下命令创建新的 .bash_profile 文件：
- When logged on as user lfs, the
- initial shell is usually a login shell which reads the /etc/profile of the host (probably containing some
- settings and environment variables) and then .bash_profile. The exec env -i.../bin/bash command in
- the .bash_profile file replaces the
- running shell with a new one with a completely empty environment,
- except for the HOME, TERM, and PS1 variables.
- This ensures that no unwanted and potentially hazardous environment
- variables from the host system leak into the build environment. The
- technique used here achieves the goal of ensuring a clean
- environment.
+ 当以 lfs 用户登陆时， shell 会先读取 /etc/profile （可能包含一些设置和环境变量），然后读取 .bash_profile 。exec env -i.../bin/bash 命令是用一个空的 shell 替换正在运行的 shell ，并保留 HOME, TERM 和 PS1 变量。这确保了不会引入主机系统中任何不必要的或者具有潜在错误的环境变量到编译环境中去，通过该命令确保了干净的编译环境。
- The new instance of the shell is a non-login shell, which does not read the
- /etc/profile or .bash_profile files, but rather reads the
- .bashrc file instead. Create the
- .bashrc file now:
+ 如果使用了 non-login shell ，则不会读取 /etc/profile 或 .bash_profile 文件的，而是读取 .bashrc 文件。立即创建 .bashrc 文件：
cat > ~/.bashrc << "EOF"
@@ -100,64 +77,24 @@
EOF
- The set +h command
- turns off bash's hash
- function. Hashing is ordinarily a useful feature—bash uses a hash table to remember
- the full path of executable files to avoid searching the PATH time and again to find the same executable.
- However, the new tools should be used as soon as they are installed.
- By switching off the hash function, the shell will always search the
- PATH when a program is to be run. As such,
- the shell will find the newly compiled tools in $LFS/tools as soon as they are available without
- remembering a previous version of the same program in a different
- location.
+ set +h 命令关闭了 bash 的哈希功能。一般来说，该功能是一个有用的功能， bash 通过哈希表记住可执行文件的完整路径，以避免一次又一次的从 PATH 变量所包含的文件夹中搜索该可执行文件。但是，一旦安装了新的工具，就应该使用新安装的程序代替旧的。通过关闭哈希功能，每次运行一个工具时， shell 就需要在 $LFS/tools 中找新编译的工具，只要存在新编译的，就不会使用不同路径下同一程序的之前的版本；
- Setting the user file-creation mask (umask) to 022 ensures that newly
- created files and directories are only writable by their owner, but
- are readable and executable by anyone (assuming default modes are
- used by the open(2) system call, new
- files will end up with permission mode 644 and directories with mode
- 755).
+ 将用户文件权限的掩码设置为 022 ，确保新创建的文件只能由文件所有者写入，但是可以由任何用户读取和执行（假设使用 open(2) 为系统调用文件的的默认方式，则新文件的权限将为 644 ，新文件夹的权限为 755）。
- The LFS variable should be set to the
- chosen mount point.
+ 设置 LFS 变量为安装系统分区的挂载点位置；
- The LC_ALL variable controls the
- localization of certain programs, making their messages follow the
- conventions of a specified country. Setting LC_ALL to “POSIX” or “C” (the two
- are equivalent) ensures that everything will work as expected in the
- chroot environment.
+ LC_ALL 变量控制某些程序的本地化，使程序的输出遵循指定国家/地区的惯例。设置 LC_ALL 为 “POSIX” 或 “C” （两者是等效的），从而确保一切安装过程按照预期在 chroot 环境中进行。
- The LFS_TGT variable sets a non-default,
- but compatible machine description for use when building our cross
- compiler and linker and when cross compiling our temporary toolchain.
- More information is contained in Section 5.2,
- “Toolchain Technical Notes”.
-
- By putting /tools/bin ahead of the
- standard PATH, all the programs installed
- in Chapter 5
- are picked up by the shell immediately after their installation.
- This, combined with turning off hashing, limits the risk that old
- programs are used from the host when the same programs are available
- in the chapter 5 environment.
+ 通过将 /tools/bin 放在标准 PATH 目录之前，确保了 第五章 中安装的程序在安装后可以立即由 shell 调用。结合关闭哈希功能，从而规避了当 第五章 中提供了新的程序时， shell 依旧调用旧程序的风险；
- Finally, to have the environment fully prepared for building the
- temporary tools, source the just-created user profile:
+ 最后，执行下面的命令，让设置的环境变量生效：
- Many people would like to know beforehand approximately how long it
- takes to compile and install each package. Because Linux From Scratch
- can be built on many different systems, it is impossible to provide
- accurate time estimates. The biggest package (Glibc) will take
- approximately 20 minutes on the fastest systems, but could take up to
- three days on slower systems! Instead of providing actual times, the
- Standard Build Unit (SBU) measure will be used instead.
+ 大多数人都想知道编译和安装每个包大概需要多长时间，因为 Linux 系统可以安装在许多不同的硬件系统上，所以不可能提供准确的预估时间。比如说， 最大的软件包 (Glibc) 在最快的硬件系统上编译安装需要大约 20 分钟，但在较慢的硬件系统上可能需要长达三天的时间！在此不提供实际时间，而使用标准构建单位 (Standard Build Unit (SBU)) 来衡量。
- The SBU measure works as follows. The first package to be compiled
- from this book is Binutils in Chapter 5.
- The time it takes to compile this package is what will be referred to
- as the Standard Build Unit or SBU. All other compile times will be
- expressed relative to this time.
+ SBU 的测量原理如下：本书在 第五章 编译的第一个包是 Binutils ，编译这个包所需的时间被称为标准构建单位或 SBU 。所有其它包的编译时间都以此来表示。
- For example, consider a package whose compilation time is 4.5 SBUs.
- This means that if a system took 10 minutes to compile and install
- the first pass of Binutils, it will take approximately 45 minutes to build this
- example package. Fortunately, most build times are shorter than the
- one for Binutils.
+ 比如说，一个编译时间为 4.5 SBU 的包，这意味着如果在一个系统中花费了 10 分钟来编译和安装 Binutils ，则需要大约 45 分钟来构建此包。不过幸运的是，大多数包构建时间都要比 Binutils 所用的短。
- In general, SBUs are not entirely accurate because they depend on
- many factors, including the host system's version of GCC. They are
- provided here to give an estimate of how long it might take to
- install a package, but the numbers can vary by as much as dozens of
- minutes in some cases.
+ 一般来说， SBU 并不完全准确。构建包所耗时间依赖许多因素，包括主机系统的 GCC 版本。在这里只是用来估计构建某个包所耗时间，但在有些情况下，误差可能多达几十分钟。
- Note
+ 注意
- For many modern systems with multiple processors (or cores) the
- compilation time for a package can be reduced by performing a
- "parallel make" by either setting an environment variable or
- telling the make
- program how many processors are available. For instance, a Core2Duo
- can support two simultaneous processes with:
+ 对于具有多个物理处理器或者多内核处理器的现代硬件系统，可以通过设置环境变量来告知 make 程序有多少处理器核心可以用来并行处理，以减少包的编译时间。例如，酷睿 2 双核处理器 (Core2Duo) 可以同时支持两个进程：
export MAKEFLAGS='-j 2'
- or just building with:
+ 或者在编译时使用以下参数：
make -j2
- When multiple processors are used in this way, the SBU units in the
- book will vary even more than they normally would. In some cases,
- the make step will simply fail. Analyzing the output of the build
- process will also be more difficult because the lines of different
- processes will be interleaved. If you run into a problem with a
- build step, revert back to a single processor build to properly
- analyze the error messages.
+ 当使用多线程编译编译包时，一个包的构建时间通常比本书所说明的多。在某些情况下， make 步骤将会失败。多进程同时编译，生成的日志文件也会交错出现，这使得分析包编译过程输出的日志也更加困难。如果在构建软件包时遇到了问题，请返回到单核心处理器进行编译，以便分析错误信息。
4.6. About the Test Suites
+ "prepare-abouttestsuites">4.6. 关于测试套件
- Most packages provide a test suite. Running the test suite for a
- newly built package is a good idea because it can provide a
- “sanity
- check” indicating that everything compiled
- correctly. A test suite that passes its set of checks usually proves
- that the package is functioning as the developer intended. It does
- not, however, guarantee that the package is totally bug free.
+ 大多数软件包都提供了一个测试套件。运行相应的测试套件，可以提供 “正确性检查” ，即检查所有的编译是否正确。这个检查是验证该软件包是否正在以开发者的意图编译运行，并不能保证这个包没有 bug 。
- Some test suites are more important than others. For example, the
- test suites for the core toolchain packages—GCC, Binutils, and
- Glibc—are of the utmost importance due to their central role in
- a properly functioning system. The test suites for GCC and Glibc can
- take a very long time to complete, especially on slower hardware, but
- are strongly recommended.
+ 有些测试套件比其他测试套件更重要，比如说核心工具链软件包 GCC, Binutils, 和 Glibc 。这些软件包在系统中处于非常重要的地位，因此进行测试是非常有必要的。 GCC 和 Glibc 的测试可能要花很长时间才能完成，特别是硬件运行速度较慢时，但依旧强烈推荐进行测试。
- Note
+ 注意
- Experience has shown that there is little to be gained from running
- the test suites in Chapter
- 5. There can be no escaping the fact that the host system
- always exerts some influence on the tests in that chapter, often
- causing inexplicable failures. Because the tools built in Chapter
- 5 are temporary and eventually discarded, we do not recommend
- running the test suites in Chapter
- 5 for the average reader. The instructions for running those
- test suites are provided for the benefit of testers and developers,
- but they are strictly optional.
+ 经验表明，在 第五章 中运行测试套件几乎不能完全通过。主机系统总是会对测试产生一定得影响，这极有可能会导致一些莫名其妙的错误。因为 第五章构建的工具都是临时的，最后会被删掉，所以我们不建议普通读者在 第五章 运行测试套件。这些测试套件是为测试人员和开发者准备的，并不是必须要运行的。
-
+
- A common issue with running the test suites for Binutils and GCC is
- running out of pseudo terminals (PTYs). This can result in a high
- number of failing tests. This may happen for several reasons, but the
- most likely cause is that the host system does not have the
- devpts file system set up correctly.
- This issue is discussed in greater detail at http://www.linuxfromscratch.org/lfs/faq.html#no-ptys.
+ 运行 Binutils 和 GCC 的测试套件时，一个常见的问题是缺少伪终端 ( PTYs ) ，这有可能会导致在测试中出现大量的错误。有多种原因可能引起这种错误，最常见的原因是 “主机系统没能正确的配置 devpts 文件系统。关于这个问题在以下链接有更详细的讨论：
+
- Sometimes package test suites will fail, but for reasons which the
- developers are aware of and have deemed non-critical. Consult the
- logs located at http://www.linuxfromscratch.org/lfs/build-logs/8.0/
- to verify whether or not these failures are expected. This site is
- valid for all tests throughout this book.
+ 有时，测试套件会报告错误，但是开发者知道并认为这是非关键性问题。请参阅位于 http://www.linuxfromscratch.org/lfs/build-logs/8.0/ 的安装日志，以便验证这些错误是否是预期性的错误。此网站适用于本书中所有的测试。
- When logged in as user root, making a
- single mistake can damage or destroy a system. Therefore, we
- recommend building the packages in this chapter as an unprivileged
- user. You could use your own user name, but to make it easier to set
- up a clean working environment, create a new user called lfs as a member of a new group (also named
- lfs) and use this user during the
- installation process. As root, issue
- the following commands to add the new user:
+ 当使用 root 用户登陆时，一点小的错误就有可能破坏整个系统。因此，我们建议使用普通用户（非特权用户）构建这些软件包。你可以使用自己的用户名，但是为了更容易配置所需的工作环境，请创建一个名为 lfs 的新用户组，并创建名字同为 lfs 的新用户作为该用户组的成员，在安装过程中将会使用此用户。以 root 用户，键入以下命令：
groupadd lfs
@@ -68,7 +60,7 @@
- The meaning of the command line options:
+ 命令中选项的含义：
@@ -77,8 +69,7 @@
- This makes bash
- the default shell for user lfs.
+ 设置 bash 为 lfs 用户的默认 shell；
@@ -87,8 +78,7 @@
- This option adds user lfs to
- group lfs.
+ 将 lfs 用户添加到 lfs 用户组；
@@ -97,8 +87,7 @@
- This creates a home directory for lfs.
+ 为 lfs 用户创建 home 文件夹；
@@ -107,10 +96,7 @@
- This parameter prevents possible copying of files from a
- skeleton directory (default is /etc/skel) by changing the input location to
- the special null device.
+ 这个选项是通过将输入位置更改为 /dev/null, 从而阻止一些可能从默认的 /etc/skel 目录复制过来文件；
@@ -119,77 +105,63 @@
- This is the actual name for the created group and user.
+ 要创建用户的实际名称。
- To log in as lfs (as opposed to
- switching to user lfs when logged in
- as root, which does not require the
- lfs user to have a password), give
- lfs a password:
+ 为 lfs 用户设置密码：
passwd lfs
- Grant lfs full access to $LFS/tools by making lfs the directory owner:
+ 将 $LFS/tools 目录的所有者更改为 lfs 用户，使 lfs 用户获取完全访问权限：
chown -v lfs $LFS/tools
- If a separate working directory was created as suggested, give user
- lfs ownership of this directory:
+ 如果按照建议创建了单独的工作目录，请使用以下命令将该目录的拥有者更改为 lfs 用户：
chown -v lfs $LFS/sources
- Next, login as user lfs. This can be
- done via a virtual console, through a display manager, or with the
- following substitute user command:
+ 接下来以 lfs 用户登陆。可以通过虚拟控制台 (Virtual Console) 、显示管理器 (Display Manager) 或以下命令切换至 lfs 用户：
su - lfs
- The “-” instructs
- su to start a login
- shell as opposed to a non-login shell. The difference between these
- two types of shells can be found in detail in bash(1) and info
- bash.
+ “-” 是指完整切换到 lfs 用户环境，即 login shell ；如果不加 “-” 则表示只切换到其他用户，即 non-login shell 。这两种切换用户的区别可以在 bash(1) 和 info bash
+ 中找到。
- All programs compiled in Chapter 5
- will be installed under $LFS/tools to
- keep them separate from the programs compiled in Chapter
- 6. The programs compiled here are temporary tools and will not be
- a part of the final LFS system. By keeping these programs in a
- separate directory, they can easily be discarded later after their
- use. This also prevents these programs from ending up in the host
- production directories (easy to do by accident in Chapter
- 5).
+ 第五章 中编译的所有程序将安装在 $LFS/tools 文件夹下，以便和 第六章 中编译的程序分离开来。第五章编译的程序是临时工具，并非最终 LFS 系统的一部分，将这些编译后的临时工具保存在单独的目录，以便在使用完成后直接删除，同时也防止了和最终的 LFS 系统相互冲突。（第五章 的工作很容易出现一些意料不到的问题。）
- Create the required directory by running the following as
- root:
+ 使用 root 用户，通过以下命令来创建所需目录：
mkdir -v $LFS/tools
- The next step is to create a /tools
- symlink on the host system. This will point to the newly-created
- directory on the LFS partition. Run this command as root as well:
+ 下一步就是在系统中创建一个 /tools 文件夹的符号链接，该链接指向 LFS 分区上新创建的目录。使用 root 用户来执行此命令：
ln -sv $LFS/tools /
@@ -88,49 +69,39 @@
- Note
+ 注意
- The above command is correct. The ln command has a few syntactic
- variations, so be sure to check info
- coreutils ln and ln(1) before reporting what you may think is an
- error.
+ 上述命令是正确的。 ln 命令有一些语法上的变化，会检查 info coreutils ln 和 ln(1) 然后报告一个错误。
- The created symlink enables the toolchain to be compiled so that it
- always refers to /tools, meaning that
- the compiler, assembler, and linker will work both in Chapter 5 (when
- we are still using some tools from the host) and in the next (when we
- are “chrooted” to the LFS partition).
+ 创建符号链接，以便始终引用 /tools 目录下的程序编译工具链。这意味着第五章新编译的编译器、汇编器和连接器将都能在第五章（仍然使用一些主机系统提供的工具时）和第六章（ chroot 到 LFS 分区中时）中使用。
- In this chapter, we will perform a few additional tasks to prepare
- for building the temporary system. We will create a directory in
- $LFS for the installation of the
- temporary tools, add an unprivileged user to reduce risk, and create
- an appropriate build environment for that user. We will also explain
- the unit of time we use to measure how long LFS packages take to
- build, or “SBUs”, and give some information about
- package test suites.
+ 在本章节中，我们将做一些额外的工作，用来准备构建临时系统。我们将在 $LFS 中创建一个用于安装临时工具的目录，添加一个非特权用户以降低风险，并且为该用户构建适当的编译环境。我们还将解释 “构建一个 $LFS 包所需时间” 的时间单位，称为 “SBU” ，并给一些关于测试套件的信息。
4.4. Setting Up the Environment
+ "ch-tools-settingenviron">4.4. 配置环境
- Set up a good working environment by creating two new startup files
- for the bash shell.
- While logged in as user lfs, issue
- the following command to create a new .bash_profile:
+ 通过为 bash shell 创建两个文件，来建立初始的环境变量。以 lfs 用户登陆，使用以下命令创建新的 .bash_profile 文件：
- When logged on as user lfs, the
- initial shell is usually a login shell which reads the /etc/profile of the host (probably containing some
- settings and environment variables) and then .bash_profile. The exec env -i.../bin/bash command in
- the .bash_profile file replaces the
- running shell with a new one with a completely empty environment,
- except for the HOME, TERM, and PS1 variables.
- This ensures that no unwanted and potentially hazardous environment
- variables from the host system leak into the build environment. The
- technique used here achieves the goal of ensuring a clean
- environment.
+ 当以 lfs 用户登陆时， shell 会先读取 /etc/profile （可能包含一些设置和环境变量），然后读取 .bash_profile 。exec env -i.../bin/bash 命令是用一个空的 shell 替换正在运行的 shell ，并保留 HOME, TERM 和 PS1 变量。这确保了不会引入主机系统中任何不必要的或者具有潜在错误的环境变量到编译环境中去，通过该命令确保了干净的编译环境。
- The new instance of the shell is a non-login shell, which does not read the
- /etc/profile or .bash_profile files, but rather reads the
- .bashrc file instead. Create the
- .bashrc file now:
+ 如果使用了 non-login shell ，则不会读取 /etc/profile 或 .bash_profile 文件的，而是读取 .bashrc 文件。立即创建 .bashrc 文件：
cat > ~/.bashrc << "EOF"
@@ -100,64 +77,24 @@
EOF
- The set +h command
- turns off bash's hash
- function. Hashing is ordinarily a useful feature—bash uses a hash table to remember
- the full path of executable files to avoid searching the PATH time and again to find the same executable.
- However, the new tools should be used as soon as they are installed.
- By switching off the hash function, the shell will always search the
- PATH when a program is to be run. As such,
- the shell will find the newly compiled tools in $LFS/tools as soon as they are available without
- remembering a previous version of the same program in a different
- location.
+ set +h 命令关闭了 bash 的哈希功能。一般来说，该功能是一个有用的功能， bash 通过哈希表记住可执行文件的完整路径，以避免一次又一次的从 PATH 变量所包含的文件夹中搜索该可执行文件。但是，一旦安装了新的工具，就应该使用新安装的程序代替旧的。通过关闭哈希功能，每次运行一个工具时， shell 就需要在 $LFS/tools 中找新编译的工具，只要存在新编译的，就不会使用不同路径下同一程序的之前的版本；
- Setting the user file-creation mask (umask) to 022 ensures that newly
- created files and directories are only writable by their owner, but
- are readable and executable by anyone (assuming default modes are
- used by the open(2) system call, new
- files will end up with permission mode 644 and directories with mode
- 755).
+ 将用户文件权限的掩码设置为 022 ，确保新创建的文件只能由文件所有者写入，但是可以由任何用户读取和执行（假设使用 open(2) 为系统调用文件的的默认方式，则新文件的权限将为 644 ，新文件夹的权限为 755）。
- The LFS variable should be set to the
- chosen mount point.
+ 设置 LFS 变量为安装系统分区的挂载点位置；
- The LC_ALL variable controls the
- localization of certain programs, making their messages follow the
- conventions of a specified country. Setting LC_ALL to “POSIX” or “C” (the two
- are equivalent) ensures that everything will work as expected in the
- chroot environment.
+ LC_ALL 变量控制某些程序的本地化，使程序的输出遵循指定国家/地区的惯例。设置 LC_ALL 为 “POSIX” 或 “C” （两者是等效的），从而确保一切安装过程按照预期在 chroot 环境中进行。
- The LFS_TGT variable sets a non-default,
- but compatible machine description for use when building our cross
- compiler and linker and when cross compiling our temporary toolchain.
- More information is contained in Section 5.2,
- “Toolchain Technical Notes”.
-
- By putting /tools/bin ahead of the
- standard PATH, all the programs installed
- in Chapter 5
- are picked up by the shell immediately after their installation.
- This, combined with turning off hashing, limits the risk that old
- programs are used from the host when the same programs are available
- in the chapter 5 environment.
+ 通过将 /tools/bin 放在标准 PATH 目录之前，确保了 第五章 中安装的程序在安装后可以立即由 shell 调用。结合关闭哈希功能，从而规避了当 第五章 中提供了新的程序时， shell 依旧调用旧程序的风险；
- Finally, to have the environment fully prepared for building the
- temporary tools, source the just-created user profile:
+ 最后，执行下面的命令，让设置的环境变量生效：
![[Note]](../images/note.png)