第3章 软件包和补丁

最新推荐文章于 2024-07-04 11:07:30 发布
最新推荐文章于 2024-07-04 11:07:30 发布
阅读量2.2k 收藏
点赞数
文章标签： compilation linker gcc bash build patch

  • 本章包含了构建一个基本的linux系统所需下载的软件包清单。对应于软件版本的版本号据知是可以工作的，而且本书是基于它们的使用。我們强烈推荐不要使用新的版本，因为对于一个版本的构建命令，对于新的版本也许就不起作用了。最新的版本也许还包含开发者都没能解决的问题。

    所有的URL，尽可能的指向位于http://www.freshmeat.net上的软件包信息页。Freshmeat页面上很容易访问官方下载站点，也有工程站点，邮件列表，FAQ，Changlog，以及更多。

    下载点也许不总是有效。当本书发布以后，如果一个下载点做了变动，Google(http://www.google.com)会提供一个有用的搜索引擎。如果搜索不成功，试试其他的下载方法，在
    http://www.linuxfromscratch.org/lfs/packages.html    有讨论。

    下载的软件包和补丁将放到某个地方，以便在整个构建过程中方便的存取。还需要一个工作目录用来解压和构建。$LFS/sources既可以用来存放软件包和补丁，又可以当作一个工作目录。通过使用这个目录，所需要的元件将会放在LFS分区上，并且在构建过程的所有步骤中都可以存取。

    要创建这个目录，在开始下载之前，使用root用户执行下列命令。

    mkdir $LFS/sources

    把目录置为可写和sticky。“sticky“指的是即使这个目录有多个用户有写权限，但是只有这个文件的拥有者(owner)才能删除该文件。下面的命令将打开可写和sticky模式。

    chmod a+wt $LFS/sources

    ---------------------------------------------------------------------------
    This chapter includes a list of packages that need to be downloaded for building a basic Linux system. The listed version numbers correspond to versions of the software that are known to work, and this book is based on their use. We highly recommend not using newer versions because the build commands for one version may not work with a newer version. The newest package versions may also have problems that work-arounds have not been developed for yet.

    All the URLs, when possible, refer to the package's information page at http://www.freshmeat.net. The Freshmeat pages provide easy access to official download sites, as well as project websites, mailing lists, FAQ, changelogs, and more.

    Download locations may not always be accessible. If a download location has changed since this book was published, Google (http://www.google.com) provides a useful search engine for most packages. If this search is unsuccessful, try one of the alternate means of downloading discussed at http://www.linuxfromscratch.org/lfs/packages.html.

    Downloaded packages and patches will need to be stored somewhere that is conveniently available throughout the entire build. A working directory is also required to unpack the sources and build them. $LFS/sources can be used both as the place to store the tarballs and patches and as a working directory. By using this directory, the required elements will be located on the LFS partition and will be available during all stages of the building process.

    To create this directory, execute, as user root, the following command before starting the download session:

    mkdir $LFS/sources

    Make this directory writable and sticky. “Sticky” means that even if multiple users have write permission on a directory, only the owner of a file can delete the file within a sticky directory. The following command will enable the write and sticky modes:

    chmod a+wt $LFS/sources

3.2、全部软件包

3.3、需要的补丁文件

第4章 最后的准备工作


4.1、关于 $LFS

  • 通篇本书，环境变量LFS将会被使用到几次。这个变量要始终被定义，这是至关重要的。您还需要设置LFS分区的挂载点。检查LFS变量是否正确设置：

    echo $LFS

    确保LFS分区的挂载点的路径，如果按照以前的例子是/mnt/lfs，如果输出不正确，变量可以这样设置：

    export LFS=/mnt/lfs

    把这个变量设置好，对于象这样的 mkdir $LFS/tools 命令是有好处的。shell会自动把 “/mnt/lfs”替换掉“$LFS”。

    当您离开又重新进入当前工作环境时，不要忘记检查$LFS是否设置。(比如当“su”到root或其他用户时)。
    -------------------------------------------------------------------------------------
    Throughout this book, the environment variable LFS will be used several times. It is paramount that this variable is always defined. It should be set to the mount point chosen for the LFS partition. Check that the LFS variable is set up properly with:

    echo $LFS

    Make sure the output shows the path to the LFS partition's mount point, which is /mnt/lfs if the provided example was followed. If the output is incorrect, the variable can be set with:

    export LFS=/mnt/lfs

    Having this variable set is beneficial in that commands such as mkdir $LFS/tools can be typed literally. The shell will automatically replace “$LFS” with “/mnt/lfs” (or whatever the variable was set to) when it processes the command line.

    Do not forget to check that $LFS is set whenever you leave and reenter the current working environment (as when doing a “su” to root or another user).

4.2、创建 $LFS/tools 目录

  • 所有在第5章编译的程序将会被安装在 $LFS/tools 目录下，为了与第6章编译的程序分离开。在这里编译的程序是临时工具，将不作为最终 LFS 系统的一部分。把这些程序放到一个单独的目录下，不需要时可以很容易的删掉他们。这也是为了防止这些程序 This also prevents these programs from ending up in the host production directories (easy to do by accident in 第5章).

    作为 root 通过下面命令创建需要的目录：

    mkdir $LFS/tools

    下一步时在主系统上创建 /tools 链接。这将指向新创建的位于 LFS 分区的目录。作为 root 运行这个命令：

    ln -s $LFS/tools /


    注意

    上面的命令是正确的。 ln 命令有一些语法变化，在您报告您认为的这是个错误之前，请阅读 info 和 man。

    被创建的链接让被编译的工具链总是指向 /tools，意味着编译器，汇编器和连接器将被本章(我们仍然要从主系统中使用一些工具时)和下一章(我们要“chrooted”到 LFS 分区时)使用。

    --------------------------------------------------------------------------------------
    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).

    Create the required directory by running the following as root:

    mkdir $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:

    ln -s $LFS/tools /


    Note

    The above command is correct. The ln command has a few syntactic variations, so be sure to check the info and man pages before reporting what you may think is an error.

    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 this chapter (when we are still using some tools from the host) and in the next (when we are “chrooted” to the LFS partition).

4.3、添加 LFS 用户

  • 当用 root 登录时，犯一个错误就足以毁坏或摧毁掉系统。因此，我們推荐在本章中，用无特权的用户来编译软件包。 您可以使用自己的用户名，但是为了使创建一个干净的工作环境更容易些，推荐创建一个新的名叫 lfs 的用户，属于也叫 lfs 的用户组，在安装过程中使用这个用户。作为 root, 输入下列命令来增加新用户：

    groupadd lfs
    useradd -s /bin/bash -g lfs -m -k /dev/null lfs

    命令行选项的意思是：

  • -s /bin/bash

    这把 bash 当作用户 lfs 的默认shell。

  • -g lfs

    这个选项增加用户 lfs 到用户组 lfs。

  • -m

    这为 lfs 用户创建一个家目录。

  • -k /dev/null

    这个参数通过把输入位置引到一个特殊的空设备，以防止从 skeleton 目录(默认是 /etc/skel)复制文件。
    lfs

    这是创建的用户组和用户的实际名字。

    要用 lfs 登录(与之相反是，当用 root 登录时切换到 lfs 用户，并不需要 lfs 用户有个密码), 得给 lfs 一个密码：

    passwd lfs

    通过把目录的 owner 设为 lfs，让 lfs 对$LFS/tools具有完全访问权限。

    chown lfs $LFS/tools

    如果单个工作目录按照建议被创建了，同样的把这个目录的 owner 设为 lfs。

    chown lfs $LFS/sources

    下一步，用 lfs 登录，您可以通过一个虚拟控制台，到达显示管理器。或用下面的替换用户命令：

    su - lfs

    “-”指示 su 开启一个登录 shell，也就是与非登录 shell 相反。这两种类型的 shell 的差异可以参考 Bash 的 man 以及 info 页。
    ---------------------------------------------------------------------------
    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 work 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:

    groupadd lfs
    useradd -s /bin/bash -g lfs -m -k /dev/null lfs

    The meaning of the command line options:

  • -s /bin/bash

    This makes bash the default shell for user lfs.

  • -g lfs

    This option adds user lfs to group lfs.

  • -m

    This creates a home directory for lfs.

  • -k /dev/null

    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.
    lfs

    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:

    passwd lfs

    Grant lfs full access to $LFS/tools by making lfs the directory owner:

    chown lfs $LFS/tools

    If a separate working directory was created as suggested, give user lfs ownership of this directory:

    chown 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:

    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 the Bash man and info pages.

4.4、设置工作环境

  • 当你登录为LFS用户时，通过建立两个启动文件设置一个好的工作环境。在终端输入以下命令建立新的 .bash_profile 文件：

     

    cat > ~/.bash_profile << "EOF"
    exec env -i HOME=$HOME TERM=$TERM PS1='/u:/w/$ ' /bin/bash
    EOF

    当你作为lfs用户登录，初始脚本通常会读取主机上的/etc/profile 文件(可能包含一些设置和环境变量)和 .bash_profile文件。 命令 exec env -i HOME=$HOME TERM=$TERM PS1='/u:/w/$ ' /bin/bash ，创建一个新的shell ，并使这个 shell 拥有完全干净的运行环境，除了"HOME"、"TERM"、和 "PS1" 变量以外。这能保证我们的编译环境不会被主机系统上有害的、潜在的危险变量影响。我们使用的这个方法能确保一个干净的环境。

     

    shell的另一个新的例子是未登录shell ：不读取 /etc/profile 文件或 .bash_profile 文件，而读取 .bashrc 文件代替。现在建立 .bashrc 文件：

    cat > ~/.bashrc << "EOF"
    set +h
    umask 022
    LFS=/mnt/lfs
    LC_ALL=POSIX
    PATH=/tools/bin:/bin:/usr/bin
    export LFS LC_ALL PATH
    EOF

    set +h 关掉bash的"hash"功能。Hashing 通常是一个有用的特性—bash 使用一个哈希表(hash table)来记住可执行文件的完整路径，以避免为查找相同的文件而反复进行路径搜索。然而，我们希望新工具一安装就尽快的使用它们。关闭 bash 功能后，当一个程序运行，shell总是会搜索路径。这样，shell 将在 $LFS/tools 目录寻找新的编译工具，使用程序的新版本。

     

    把用户文件创建掩码(umask) 设为022 确保 新建文件和目录仅对他们的属主可写， 但是能被任何人读取和运行 (assuming default modes are used by the open(2) system call，新文件许可模式为644 目录许可模式为755)。

    LFS变量应该设成你选择的挂载点。

    LC_ALL 变量控制某些程式的本地化，使它们的信息遵循指定国家的规范。如果主机使用的 Glibc 低于 2.2.4 版本时，把 LC_ALL 设为“POSIX”或“C”以外的值(在本章)，退出chroot 环境后再次回到原来环境时可能会有麻烦。把 LC_ALL 设为“POSIX”或“C”(这两个值等价)能确保程序在chroot 环境中像预期的那样运行。

    把 /tools/bin 放在标准路径前面， 所有在第五章安装的程序安装后就能马上运行。 这点和"关掉 hashing 功能"结合起来，限制了当他们没被使用时，再次使用主机上的旧程序的风险 。

    最后， 为建造临时工具设定充分的环境变量，source 我们刚建立的profile文件：

    source ~/.bash_profile

     

    >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    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 :

     

    cat > ~/.bash_profile << "EOF"
    exec env -i HOME=$HOME TERM=$TERM PS1='/u:/w/$ ' /bin/bash
    EOF

    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.

     

    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:

    cat > ~/.bashrc << "EOF"
    set +h
    umask 022
    LFS=/mnt/lfs
    LC_ALL=POSIX
    PATH=/tools/bin:/bin:/usr/bin
    export LFS LC_ALL PATH
    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.

     

    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).

    The LFS variable should be set to the chosen mount point.

    The LC_ALL variable controls the localization of certain programs, making their messages follow the conventions of a specified country. If the host system uses a version of Glibc older than 2.2.4, having LC_ALL set to something other than “POSIX” or “C” (during this chapter) may cause issues if you exit the chroot environment and wish to return later. Setting LC_ALL to “POSIX” or “C” (the two are equivalent) ensures that everything will work as expected in the chroot environment.

    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 from the host are being used when they should not be used any longer.

    Finally, to have the environment fully prepared for building the temporary tools, source the just-created user profile:

    source ~/.bash_profile

     

4.5、关于 SBUs

  • 许多人想知道编译和安装每个软件包大概要用多少时间。 因为 Linux From Scratch 能在许多不同的系统上建立， 所以我们无法给定一个准确的时间。 最大的包 (Glibc) 在较快的系统上编译可能要用20分钟，但是在慢的系统上可能要3天！代替具体时间的，是使用 静态 Binutils 单位时间(简称 SBU )。

    SBU 是这样测量的。假如第一个被编译的包是第五章里静态连接的 Binutils。 编译这个包用的时间就作为是静态“Binutils 单位时间”。所有其它软件包的编译时间相对于这个时间来表示。

    例如，假定一个软件包的编译时间是 4.5 SBUs。这意味着如果一个系统花10 分钟编译和安装静态 Binutils，这个软件包大约要用 45 分钟编译例子中的软件包。 幸运的是多数的编译时都比一个 Binutils 时间短。

    请注意，如果你的主机系统基于 GCC-2.x ，那么列出的SBU可能不是很准确。这是因为 SBU 是基于第一个软件包的，第一个软件包在旧的 GCC 上编译， 而其余的软件编译时使用的新于 GCC-3.4.1 (已知这样大约慢30%)。 在SMP(多处理器)的系统上 SBUs 也不是很准确。

    要查看许多不同系统编译要用的真实时间， 我们推荐 http://www.linuxfromscratch.org/~bdubbs/。

    通常， SBUs 不是很准因为它不仅受 GCC 版本的影响，它要依靠太多的因素 。 它作出多长时间可以安装一个包的估计， 但是这个数字在每分钟都可能因情况而改变。

    ---------------------------------------------------------------------------------------------------------

    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 Static Build Unit (SBU) measure will be used instead.

    The SBU measure works as follows. The first package to be compiled from this book is the statically-linked Binutils in Chapter 5. The time it takes to compile this package is what will be referred to as the Static Build Unit or SBU. All other compile times will be expressed relative to this time.

    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 static Binutils, it will take approximately 45 minutes to build this example package. Fortunately, most build times are shorter than the one for Binutils.

    Please note that if the system compiler on the host is GCC-2.x based, the SBUs listed may be somewhat understated. This is because the SBU is based on the very first package, compiled with the old GCC, while the rest of the system is compiled with the newer GCC-3.4.1 (which is known to be approximately 30 percent slower). SBUs are also not highly accurate for Symmetric Multi-Processor (SMP)-based machines.

    To view actual timings for a number of specific machines, we recommend http://www.linuxfromscratch.org/~bdubbs/.

    In general, SBUs are not very accurate because they depend on many factors, not just the GCC version. 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.

4.6、关于软件包的测试套件

  • (本页待修改，需对照)
    大多数软件包提供测试程序集。新编译了一个软件包之后就运行一下它提供的测试程序是个好主意，因为测试将进行一次“健全检查”来确认所有的代码是否都正确编译了。通过了测试程序集的一系列检查的话，这就意味着软件包在开发者看来已经正常工作了。当然，这并不保证这个软件包就完全没有 bug 了。
    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.

    某些测试程序集是极为重要的，例如核心工具链软件包--GCC、Binutils、Glibc--的测试程序，因为这些软件包在一个良好工作的系统里的所处的中心角色。GCC 和 Glibc 的测试程序需要运行很长时间，尤其在速度慢的硬件上，但我们仍然强烈推荐您运行这些测试程序。
    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.

    注意

    经验显示运行第五章的测试程序的时候会有点小问题，不可否认宿主系统总是对这一章的测试程序施加了某些影响，常常导致无法解释的测试失败。因为第五章编译的工具是临时的而且在最后会被丢弃的，我们不推荐平均水平的读者运行这一章的测试程序。这些测试程序的指令是为开发和测试人员准备的，而不是必需的。
    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.

    Binutils 和 GCC 的测试程序一个常见的问题就是在伪终端(PTYs)外运行，这样可能会出现大量的测试失败。可能的原因有几个，但最可能的因素就是宿主系统没有正确的设置 devpts 文件系统，这个问题在第五章有详细的讨论。
    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 in Chapter 5.

    某些软件包测试程序可能会给出错误的失败信息，请参考 LFS Wiki http://wiki.linuxfromscratch.org/ 以确认您所遇到的测试失败是否是预期会出现的。这个站点的内容对于本书所有的测试都是正确的。
    Sometimes package test suites will give false failures. Consult the LFS Wiki at http://wiki.linuxfromscratch.org/ to verify that these failures are expected. This site is valid for all tests throughout this book.

第5章 构建临时编译环境


5.01、简介

  • 本章介绍如何编译和安装一个最小的 Linux 系统。这个系统将仅包含必要的工具，能够构建第6章中最终的LFS系统，
    This chapter shows how to compile and install a minimal Linux system. This system will contain just enough tools to start constructing the final LFS system in and allow a working environment with more user convenience than a minimum environment would.

    构建这个最小系统分两步进行，第一步是构建一个新的依赖于宿主系统的工具链(编译器，汇编器，连接器，库文件以及一些有用的软件)。第二个步骤是利用这个工具链去构建其它基本的工具。
    There are two steps in building this minimal system. The first step is to build a new and host-independent toolchain (compiler, assembler, linker, libraries, and a few useful utilities). The second step uses this toolchain to build the other essential tools.

    本章中编译的文件将安装在 $LFS/tools 目录下，这样可以与下一章将安装的软件以及宿主系统的区分开来。这些软件包编译出来是起临时作用的，我们不希望这些软件和即将建立的 LFS 系统混杂在一起。
    The files compiled in this chapter will be installed under the $LFS/tools directory to keep them separate from the files installed in the next chapter and the host production directories. Since the packages compiled here are temporary, we do not want them to pollute the soon-to-be LFS system.

    在运行一个软件包的编译指令之前，需要用 lfs 用户解开这个软件包，并用 cd 命令进入软件包解开后的目录。编译指令假定您使用的是 Bash Shell。
    Before issuing the build instructions for a package, the package should be unpacked as user lfs, and a cd into the created directory should be performed. The build instructions assume that the bash shell is in use.

    某些软件包编译之前需要打上补丁，但仅仅是需要补丁来解决某个问题的时候。一个补丁可能本章和下一章都会用到，也可能只在某一章才会用到。因此，当某个指令看起来需要下载一个补丁，但是这个补丁并不存在的时候，不需要考虑太多。而应用某个补丁的时候，也可能会出现某些关于偏移量和模糊的警告信息，不要理会，这个补丁仍然会被成功的应用。
    Several of the packages are patched before compilation, but only when the patch is needed to circumvent a problem. A patch is often needed in both this and the next chapter, but sometimes in only one or the other. Therefore, do not be concerned if instructions for a downloaded patch seem to be missing. Warning messages about offset or fuzz may also be encountered when applying a patch. Do not worry about these warnings, as the patch was still successfully applied.

    编译大多数软件包的过程中，屏幕上可能会滚过一些警告信息，这些是正常且可以被安全忽略的。这些警告就像显示的那样--警告的是不标准，却不是不正确的 C 或 C++ 语法。C 标准常常会变，而某些软件包仍然使用老的标准，这不是问题，仅仅导致一些警告信息而已。
    During the compilation of most packages, there will be several warnings that scroll by on the screen. These are normal and can safely be ignored. These warnings are as they appear—warnings about deprecated, but not invalid, use of the C or C++ syntax. C standards change fairly often, and some packages still use the older standard. This is not a problem, but does prompt the warning.

    在安装完每个软件包之后，删除源文件和编译目录，除非另有特别的指令。删除源文件可以节省磁盘空间，并且可以在下次需要安装同一个软件包的时候不会有错误的配置。只有三个软件包需要保留源文件和编译目录，接下来的命令需要用到，请特别注意这些软件包的提示。
    After installing each package, delete its source and build directories, unless specifically instructed otherwise. Deleting the sources saves space and prevents mis-configuration when the same package is reinstalled later. Only three of the packages need to retain the source and build directories in order for their contents to be used by later commands. Pay special attention to these reminders.

    最后检查 LFS 环境变量是否设置正确：
    Check one last time that the LFS environment variable is set up properly:

    echo $LFS

    请确认输出的是挂载 LFS 分区的路径，在我们的例子中，是 /mnt/lfs。
    Make sure the output shows the path to the LFS partition's mount point, which is /mnt/lfs, using our example.

5.02、宿主系统要求

  • 宿主系统必须使用 GCC-3.0 或更高版编译的，最低2.6.2的内核。这么高的要求有两个原因.第一，如果内核没有用 GCC-3.0 或更高版本编译的话，那么本地 POSIX 线程库(NPTL)将会出错。第二，Udev需要2.6.2或更高版本的内核。Udev通过读取 sysfs 文件系统动态的创建设备。不过，这种文件系统的支持是最近才加进了内核中的。我们必须保证所有关键的系统设备能正确的创建。

    为了能确定宿主系统的内核是否符合上述要求，运行下列命令:

    cat /proc/version

    将会产生类似的输出：

    Linux version 2.6.2 (user@host) (gcc version 3.4.0) #1
    Tue Apr 20 21:22:18 GMT 2004

    如果命令输出的结果显示，宿主系统的内核不是用 GCC-3.0 或者更高版本编译的，您将需要重新编译一个。然后，宿主系统需要重启以使用新编译好的内核，关于内核编译以及配置 启动装载器(假定使用GRUB)，位于 第八章.

    -------------------------------------------------

    The host must be running at least a 2.6.2 kernel compiled with GCC-3.0 or higher. There are two main reasons for this high requirement. First, the Native POSIX Threading Library (NPTL) test suite will segfault if the host's kernel has not been compiled with GCC-3.0 or a later version. Secondly, the 2.6.2 or later version of the kernel is required for the use of Udev. Udev creates devices dynamically by reading from the sysfs file system. However, support for this filesystem has only recently been implemented in most of the kernel drivers. We must be sure that all critical system devices get created properly.

    In order to determine whether the host kernel meets the requirements outlined above, run the following command:

    cat /proc/version

    This will produce output similar to:

    Linux version 2.6.2 (user@host) (gcc version 3.4.0) #1
    Tue Apr 20 21:22:18 GMT 2004

    If the results of the above command state that the host kernel was not compiled using a GCC-3.0 (or later) compiler, one will need to be compiled. The host system will then need to be rebooted to use the newly compiled kernel. Instructions for compiling the kernel and configuring the boot loader (assuming the host uses GRUB) are located in Chapter 8.

5.03、工具链技术说明

  • 5.3. 工具链技术说明

    本小节将解释隐藏在整个构建方法背后的一些合理的和技术的细节。您不必需立即理解本节中的所有。大多数的信息在您执行实际的构建之后，将会变得清晰起来。您可以在任何时候回顾本节。

    第5章的整个目标是提供一个您可以用 chroot 命令进去的临时环境， 以便于在第六章里使用这个环境，创建干净、健壮的 LFS 目标系统。为了与主系统尽可能地分离，我们创建一个独立自足的工具链。值得注意的是，工具链的创建工程被设计成在尽量减少新读者犯错可能的同时，提供最大的教育价值。也就是说，还有些更高级的技术可用于创建系统。

    重要

    继续之前，要注意工作平台的名称，也就是通常所指的 target triplet。target triplet 会有可能是 i686-pc-linux-gnu。要得到 target triplet 的名称的一个简单方法是运行 config.guess 脚本，许多软件包都有附带。解压开 Binutils 包，然后运行脚本： ./config.guess 并注意输出。

    另外也要注意平台的动态连接器的名称，也是通常所指的动态装载器(不要与 Binutils 所带的标准连接器弄混淆了)。Glibc 提供的动态连接器是用来寻找和装载程序所需的共享库，为程序运行做准备，然后运行之。动态连接器的名称一般都会是 ld-linux.so.2。在少量的平台上会不一样，名称有可能是 ld.so.1，较新的64位平台也可能名称完全变成别的。 平台之动态连接库的名称可以在主系统的 /lib 目录下面得到。一个 sure-fire 的方法是在主系统上随便找个二进制文件，运行： readelf -l <二进制文件名> | grep interpreter，然后注意输出。涵盖所有平台的认证参考是在 shlib-versions 文件，位于 Glibc 源码树之根目录。

     

    一些技术要点，关于第5章 之构建方法的：

  • The process is similar in principle to cross-compiling, whereby tools installed in the same prefix work in cooperation, and thus utilize a little GNU “magic”
  • 小心处理标准连接器的库搜索路径，确保程序被连接到所选择的库上。
  • 小心处理 gcc 的 specs 文件，告诉编译器目标系统将使用动态连接器。

    Binutils 首先被安装，因为 GCC 和 Glibc 的./configure 所执行的关于汇编器和连接器的各种特性测试，将决定哪些软件功能被打开或关上。大家首先要认识到，这步是很重要的。配置不正确将导致破损的工具链，像这种漏洞也许会到整个编译快完成的时候才显示出来。测试套件失败将能够在许多额外的工作进行之前把错误警告出来。

    Binutils 把汇编器和连接器安装在两个位置，/tools/bin 和 /tools/$TARGET_TRIPLET/bin。其中一个位置的工具是硬连接。连接器的一个重要的地方是库搜索顺序。关于细节可以通过 ld 的 --verbose 选项获得。举个例子，ld --verbose | grep SEARCH 将列出当前的搜索路径以及它们的顺序。要显示那些文件被 ld 连接到一个空(dummy)程序，可以传递 --verbose 到连接器。举个例子， gcc dummy.c -Wl,--verbose 2>&1 | grep succeeded 将显示在连接过程中所有成功被打开的文件。

    下一个被安装的软件包是 GCC。有一个运行 ./configure 的例子：

    checking what assembler to use... 
        /tools/i686-pc-linux-gnu/bin/as
checking what linker to use... /tools/i686-pc-linux-gnu/bin/ld

    基于以上原因，这步很重要。它也显示 GCC 的配置脚本没有通过 PATH (译者注：linux下的路径环境变量)来搜索使用工具的目录。而且，在 gcc 实际的操作中，相同的搜索路径不一定被使用。要找出 gcc 将使用哪个标准连接器，运行： gcc -print-prog-name=ld.

    在编译一个空(dummy)程序时，可通过给 gcc 加上 -v 选项，来获得细节信息。举例说明, gcc -v dummy.c 将显示在预处理，编译和汇编过程中的细节信息。包含 gcc 的include 搜索路径和他们的顺序。

    下个安装的软件包是 Glibc。在编译 Glibc 时，最需注意的地方是编译器，二进制工具(译者注：就是/bin下的工具)和内核头文件。编译器通常不是个问题，因为 Glibc 将总是通过 PATH 来寻找 gcc。二进制工具和内核头文件可能有一点复杂。因此，避免冒险，使用已有的开关选项来保证正确的选择。运行 ./configure后，在glibc-build 下的 config.make 文件中，查看所有重要的细节。使用 CC="gcc -B/tools/bin/" 去控制哪些二进制工具被使用，使用 -nostdinc 和 -isystem 标签选项去控制编译器的 include 搜索路径。这些选项表明了 Glibc 的一个重要的方面—即根据它的编译机制，它是非常自足的，并通常默认不依赖工具链。

    Glibc 安装之后，要做一些调整以确保搜索和连接仅发生在 /tools 目录下。安装一个调整过的 ld，把它的 hard-wired 搜索路径限制在 /tools/lib目录下。然后修改 gcc 的 specs 文件以指向新的位于 /tools/lib的动态连接器。这最后一步在整个过程中至关重要。就象以上所提及的，一个指向动态连接器的 hard-wired 路径被嵌入到每个 Executable and Link Format (ELF)-shared 可执行格式。(译者注：ELF是linux上通用的可执行格式，就像windows下的PE格式)。可运行: readelf -l | grep interpreter 来检查。修改 gcc 的 specs 文件确保通篇本章所有被编译的程序将会使用位于 /tools/lib 下的新的动态连接器。

    需要新的动态连接器也是为何在 GCC 第二遍要打 Specs 补丁的原因。如果失败，将会导致 GCC 把位于主系统的 /lib 目录下的动态连接器嵌入进来，这将有悖于于主系统脱离开的目标。

    在 Binutils 第二遍，我們可以使用 --with-lib-path 配置开关来控制 ld 的库搜索路径。从这点出发，核心的工具链就是自包含(self-contained)和自提供(self-hosted)。第5章 余下的软件包都被编译到位于/tools 目录下的 Glibc。

    在 第6章进入 chroot 环境, 首个主要的安装的软件包是 Glibc，因为以上提及的，它是自充足的(self-sufficient)。一旦 Glibc 被安装到 /usr 目录下后，接着快速从工具链转换到新系统，然后进行余下的 LFS 系统的编译。

    5.3.1. 静态连接的提示

    大多数程序除了它们特定的任务之外，还要做一些通常的，有时是琐碎的操作。这些包括分配内存，搜索目录，读写文件，字串处理，类型匹配，计算以及其它的任务。除了热心帮助每个程序避免重新发明轮子，GNU 系统还提供了所有基本函数库。在任何linux下的这个主要的库就是 Glibc。

    一个程序要使用库函数，有二种基本的方式－静态的或动态的。当一个程序被静态连接，那么被使用函数的代码就被包含到可执行格式中去了，结果是一个相当笨重的程序。当一个程序被动态连接，它只包含一个动态连接器的索引，库的名称和函数的名称，这会得到一个小的多的程序。第三个选项是使用动态连接器的编程接口(请参考 dlopen man page 获取更多的信息)。

    linux 下默认是动态连接，相对于静态连接有三大优点。第一，可执行库代码只需一份拷贝放到硬盘中，取代之包含在不同的程序中的相同的代码却要多份拷贝，因而节省磁盘空间。第二，当多个程序在同时使用同一个库函数时，只需一份函数代码的拷贝，因而节省内存空间。第三，当一个库函数做了修正或被改进了，只需库函数本身需要重新编译，取代之所有使用该函数的程序被重新编译。

    既然动态连接有这么多的好处，为何在本章中头两个软件包却要静态连接呢？原因有三－－历史的，教育的和技术的。 历史的原因是早期的 LFS 版本在本章中需要静态连接。教育性的，是让大家知道静态连接和动态连接的区别。技术上的好处是获得与主系统脱离开，意味着那些程序能够脱离于主系统而被使用。但是如果头两个软件包被动态连接，整个 LFS 构建仍能够成功的。

    --------------------------------------------------------------------------------------

    5.3. Toolchain Technical Notes

    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 back to at any time during the process.

    The overall goal of Chapter 5 is to provide a temporary environment that can be chrooted into and from which can be produced a clean, trouble-free build of the target LFS system in Chapter 6. Along the way, we separate from the host system as much as possible, and in doing so, build a self-contained and self-hosted toolchain. It should be noted that the build process has been designed to minimize the risks for new readers and provide maximum educational value at the same time. In other words, more advanced techniques could be used to build the system.

    Important

    Before continuing, be aware of the name of the working platform, often referred to as the target triplet. Many times, the target triplet will probably be i686-pc-linux-gnu. A simple way to determine the name of the target 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.

    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 ld that is part of Binutils). The dynamic linker provided by 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 will usually be ld-linux.so.2. On platforms that are less prevalent, the name might be ld.so.1, and newer 64 bit platforms might be named something else entirely. The name of the platform's dynamic linker can be determined by looking in the /lib directory on the host system. A sure-fire way to determine the name is to inspect a random binary from the host system by running: readelf -l | grep interpreter and noting the output. The authoritative reference covering all platforms is in the shlib-versions file in the root of the Glibc source tree.

     

    Some key technical points of how the Chapter 5 build method works:

  • The process is similar in principle to cross-compiling, whereby tools installed in the same prefix work in cooperation, and thus utilize a little GNU “magic”
  • Careful manipulation of the standard linker's library search path ensures programs are linked only against chosen libraries
  • Careful manipulation of gcc's specs file tell the compiler which target dynamic linker will be used

    Binutils is installed first because the ./configure 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 alert this error before too much additional work is performed.

    Binutils installs its assembler and linker in two locations, /tools/bin and /tools/$TARGET_TRIPLET/bin. 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 ld by passing it the --verbose flag. For example, an ld --verbose | grep SEARCH will illustrate the current search paths and their order. It shows which files are linked by ld by compiling a dummy program and passing the --verbose switch to the linker. For example, gcc dummy.c -Wl,--verbose 2>&1 | grep succeeded will show all the files successfully opened during the linking.

    The next package installed is GCC. An example of what can be seen during its run of ./configure is:

    checking what assembler to use... 
        /tools/i686-pc-linux-gnu/bin/as
checking what linker to use... /tools/i686-pc-linux-gnu/bin/ld

    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 gcc itself, the same search paths are not necessarily used. To find out which standard linker gcc will use, run: gcc -print-prog-name=ld.

    Detailed information can be obtained from gcc by passing it the -v command line option while compiling a dummy program. For example, gcc -v dummy.c will show detailed information about the preprocessor, compilation, and assembly stages, including gcc's included search paths and their order.

    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 gcc found in a PATH directory. The binary tools and kernel headers can be a bit more complicated. Therefore, take no risks and use the available configure switches to enforce the correct selections. After the run of ./configure, check the contents of the config.make file in the glibc-build directory for all important details. Note the use of CC="gcc -B/tools/bin/" to control which binary tools are used and the use of the -nostdinc and -isystem flags to control the compiler's include search path. These items highlight an important aspect of the Glibc package—it is very self-sufficient in terms of its build machinery and generally does not rely on toolchain defaults.

    After the Glibc installation, make some adjustments to ensure that searching and linking take place only within the /tools prefix. Install an adjusted ld, which has a hard-wired search path limited to /tools/lib. Then amend gcc's specs file to point to the new dynamic linker in /tools/lib. This last step is vital to the whole process. As mentioned above, a hard-wired path to a dynamic linker is embedded into every Executable and Link Format (ELF)-shared executable. This can be inspected by running: readelf -l | grep interpreter. Amending gcc's specs file ensures that every program compiled from here through the end of this chapter will use the new dynamic linker in /tools/lib.

    The need to use the new dynamic linker is also the reason why the Specs patch is applied for the second pass of GCC. Failure to do so will result in the GCC programs themselves having the name of the dynamic linker from the host system's /lib directory embedded into them, which would defeat the goal of getting away from the host.

    During the second pass of Binutils, we are able to utilize the --with-lib-path configure switch to control ld's library search path. From this point onwards, the core toolchain is self-contained and self-hosted. The remainder of Chapter 5 packages all build against the new Glibc in /tools.

    Upon entering the chroot environment in Chapter 6, the first major package to be installed is Glibc, due to its self-sufficient nature mentioned above. Once this Glibc is installed into /usr, perform a quick changeover of the toolchain defaults, then proceed in building the rest of the target LFS system.

    5.3.1. Notes on Static Linking

    Besides their specific task, most programs have to perform many common and sometimes trivial operations. These include allocating memory, searching directories, reading and writing files, string handling, pattern matching, arithmetic, and other tasks. Instead of obliging each program to reinvent the wheel, the GNU system provides all these basic functions in ready-made libraries. The major library on any Linux system is Glibc.

    There are two primary ways of linking the functions from a library to a program that uses them—statically or dynamically. When a program is linked statically, the code of the used functions is included in the executable, resulting in a rather bulky program. When a program is dynamically linked, it includes a reference to the dynamic linker, the name of the library, and the name of the function, resulting in a much smaller executable. A third option is to use the programming interface of the dynamic linker (see the dlopen man page for more information).

    Dynamic linking is the default on Linux and has three major advantages over static linking. First, only one copy of the executable library code is needed on the hard disk, instead of having multiple copies of the same code included in several programs, thus saving disk space. Second, when several programs use the same library function at the same time, only one copy of the function's code is required in core, thus saving memory space. Third, when a library function gets a bug fixed or is otherwise improved, only the one library needs to be recompiled instead of recompiling all programs that make use of the improved function.

    If dynamic linking has several advantages, why then do we statically link the first two packages in this chapter? The reasons are threefold—historical, educational, and technical. The historical reason is that earlier versions of LFS statically linked every program in this chapter. Educationally, knowing the difference between static and dynamic linking is useful. The technical benefit is a gained element of independence from the host, meaning that those programs can be used independently of the host system. However, it is worth noting that an overall successful LFS build can still be achieved when the first two packages are built dynamically.

5.04、Binutils-2.15.91.0.2 - 第一次编译

  • The Binutils package contains a linker, an assembler, and other tools for handling object files.

    Approximate build time: 1.0 SBU

    Required disk space: 194 MB

    Binutils installation depends on: Bash, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make, Perl, Sed, and Texinfo

    5.4.1. Installation of Binutils

    It is important that Binutils be the first package compiled because both Glibc and GCC perform various tests on the available linker and assembler to determine which of their own features to enable.

    This package is known to have issues when its default optimization flags (including the -march and -mcpu options) are changed. If any environment variables that override default optimizations have been defined, such as CFLAGS and CXXFLAGS, unset them when building Binutils.

    The Binutils documentation recommends building Binutils outside of the source directory in a dedicated build directory:

    mkdir ../binutils-build
cd ../binutils-build

    Note

    In order for the SBU values listed in the rest of the book to be of any use, measure the time it takes to build this package from the configuration, up to and including the first install. To achieve this easily, wrap the four commands in a time command like this: time { ./configure ... && ... && ... && make install; }.

    Now prepare Binutils for compilation:

    ../binutils-2.15.91.0.2/configure --prefix=/tools /
    --disable-nls

    The meaning of the configure options:

  • --prefix=/tools

    This tells the configure script to prepare to install the Binutils programs in the /tools directory.

  • --disable-nls

    This disables internationalization. This is not needed for the static programs, and NLS can cause problems when linking statically.

    Continue with compiling the package:

    make configure-host
make LDFLAGS="-all-static"

    The meaning of the make parameters:

  • configure-host

    This forces all subdirectories to be configured immediately. A statically-linked build will fail without it. Use this option to work around the problem.

  • LDFLAGS="-all-static"

    This tells the linker that all Binutils programs should be linked statically. However, strictly speaking, "-all-static" is passed to the libtool program, which then passes "-static" to the linker.

    Compilation is now complete. Ordinarily we would now run the test suite, but at this early stage the test suite framework (Tcl, Expect, and DejaGNU) is not yet in place. The benefits of running the tests at this point are minimal since the programs from this first pass will soon be replaced by those from the second.

    Install the package:

    make install

    Next, prepare the linker for the “Adjusting” phase later on:

    make -C ld clean
make -C ld LDFLAGS="-all-static" LIB_PATH=/tools/lib

    The meaning of the make parameters:

  • -C ld clean

    This tells the make program to remove all compiled files in the ld subdirectory.

  • -C ld LDFLAGS="-all-static" LIB_PATH=/tools/lib

    This option rebuilds everything in the ld subdirectory. Specifying the LIB_PATH Makefile variable on the command line allows us to override the default value and point it to the temporary tools location. The value of this variable specifies the linker's default library search path. This preparation is used later in the chapter.


    Warning

    Do not remove the Binutils build and source directories yet. These will be needed again in their current state later in this chapter.

    Details on this package are located in Section 6.13.2, “Contents of Binutils.”

5.05、GCC-3.4.1 - 第一次编译

  • The GCC package contains the GNU compiler collection, which includes the C and C++ compilers.

    Approximate build time: 4.4 SBU

    Required disk space: 300 MB

    GCC installation depends on: Bash, Binutils, Coreutils, Diffutils, Findutils, Gawk, Gettext, Glibc, Grep, Make, Perl, Sed, and Texinfo

    5.5.1. Installation of GCC

    Unpack only the gcc-core tarball because neither the C++ compiler nor the test suite will be needed here.

    This package is known to have issues when its default optimization flags (including the -march and -mcpu options) are changed. If any environment variables that override default optimizations have been defined, such as CFLAGS and CXXFLAGS, unset them when building GCC.

    The GCC documentation recommends building GCC outside of the source directory in a dedicated build directory:

    mkdir ../gcc-build
cd ../gcc-build

    Prepare GCC for compilation:

    ../gcc-3.4.1/configure --prefix=/tools /
    --libexecdir=/tools/lib --with-local-prefix=/tools /
    --disable-nls --enable-shared --enable-languages=c

    The meaning of the configure options:

  • --with-local-prefix=/tools

    The purpose of this switch is to remove /usr/local/include from gcc's include search path. This is not absolutely essential, however, it helps to minimize the influence of the host system.

  • --enable-shared

    This switch may seem counter-intuitive at first. However, this switch allows the building of libgcc_s.so.1 and libgcc_eh.a, and having libgcc_eh.a available ensures that the configure script for Glibc (the next package we compile) produces the proper results. Note that the GCC binaries will still be linked statically because this is controlled by the -static value of the BOOT_LDFLAGS variable in the next step.

  • --enable-languages=c

    This option ensures that only the C compiler is built. This option is only needed when you have downloaded and unpacked the full GCC tarball, as opposed to just the gcc-core tarball.

    Continue with compiling the package:

     
 make BOOT_LDFLAGS="-static" bootstrap

    The meaning of the make parameters:

  • BOOT_LDFLAGS="-static"

    This tells GCC to link its programs statically.

  • bootstrap

    This target does not just compile GCC, but compiles it several times. It uses the programs compiled in a first round to compile itself a second time, and then again a third time. It then compares these second and third compiles to make sure it can reproduce itself flawlessly. This also implies that it was compiled correctly.

    Compilation is now complete. At this point, the test suite would normally be run, but, as mentioned before, the test suite framework is not in place yet. The benefits of running the tests at this point are minimal since the programs from this first pass will soon be replaced.

    Install the package:

    make install

    As a finishing touch, create a symlink. Many programs and scripts run cc instead of gcc, which is used to keep programs generic and therefore usable on all kinds of UNIX systems where the GNU C compiler is not always installed. Running cc leaves the system administrator free to decide which C compiler to install.

    ln -s gcc /tools/bin/cc

    Details on this package are located in Section 6.14.2, “Contents of GCC.”

5.06 Linux-Libc-Headers -2.6.8.1

  • Linux-Libc-Headers 软件包的内容：“被清理过”的内核头文件。

    预计编译时间： 0.1 SBU

    所需硬盘空间：22 MB

    Linux-Libc-Headers 依赖于： Coreutils

    5.6.1. 安装 Linux-Libc-Headers

    在以前，通常的做法是，直接从内核源文件包中把内核自带的头文件取出，放在 /usr/include 中来使用。但是最近几年，内核开发人员强烈要求停止这种做法。因此诞生了 Linux-Libc-Headers 项目，其目的就是维护一个 Linux 头文件的稳定版本。

    安装这些头文件：

    cp -R include/asm-i386 /tools/include/asm
cp -R include/linux /tools/include

    如果您的计算机不是 i386 架构（或者与之兼容），请调整第一条指令。

    本软件包的详细内容请参考 Section 6.9.2, “Contents of Linux-Libc-Headers.”

     


    此节译毕。 performcanhe 2005/04/10 19:15

     

    The Linux-Libc-Headers package contains the “sanitized” kernel headers.

    Approximate build time: 0.1 SBU

    Required disk space: 22 MB

    Linux-Libc-Headers installation depends on: Coreutils

    5.6.1. Installation of Linux-Libc-Headers

    For years it has been common practice to use “raw” kernel headers (straight from a kernel tarball) in /usr/include, but over the last few years, the kernel developers have taken a strong stance that this should not be done. This gave birth to the Linux-Libc-Headers Project, which was designed to maintain an Application Programming Interface (API) stable version of the Linux headers.

    Install the header files:

    cp -R include/asm-i386 /tools/include/asm
cp -R include/linux /tools/include

    If your architecture is not i386 (compatible), adjust the first command accordingly.

    Details on this package are located in Section 6.9.2, “Contents of Linux-Libc-Headers.”

5.07、Linux-2.6.8.1 Headers

  • Linux 内核软件包包含了内核源代码，当然也包含了供 Glibc 使用的头文件。

    大约编译时间：0.1 SBU

    需要磁盘空间： 186 MB

    Linux 头文件安装依赖： Coreutils and Make

    5.7.1. 内核头文件的安装

    因为有些软件包需要引用内核头文件，现在是时候解压内核包，把所需文件放到 gcc 以后能够找到的地方。

    头文件安装准备：

    make mrproper

    这将确保内核树绝对的干净。我們推荐在每次内核编译之前都使用这个命令。不要假设解压开后，内核包应该自动的是干净的。

    创建 include/linux/version.h 文件：

    make include/linux/version.h

    创建平台特定的 include/asm 链接：

    make include/asm

    安装平台特定的头文件：

    mkdir /tools/glibc-kernheaders
cp -HR include/asm /tools/glibc-kernheaders
cp -R include/asm-generic /tools/glibc-kernheaders

    最后，安装跨平台的内核头文件：

    cp -R include/linux /tools/glibc-kernheaders

    这个软件包的细节位于 8.3.2小节, “Contents of Linux.”

    ---------------------------------------------------------------------------
    The Linux kernel package contains the kernel source as well as the header files used by Glibc.

    Approximate build time: 0.1 SBU

    Required disk space: 186 MB

    Linux Headers installation depends on: Coreutils and Make

    5.7.1. Installation of the Kernel Headers

    Because some packages need to refer to the kernel header files, now is a good time to unpack the kernel archive, set it up, and copy the required files to a place where gcc can locate them later.

    Prepare for the header installation with:

    make mrproper

    This ensures that the kernel tree is absolutely clean. It is recommended that this command be issued prior to each kernel compilation. Do not assume that the source tree is automatically clean after un-tarring.

    Create the include/linux/version.h file:

    make include/linux/version.h

    Create the platform-specific include/asm symlink:

    make include/asm

    Install the platform-specific header files:

    mkdir /tools/glibc-kernheaders
cp -HR include/asm /tools/glibc-kernheaders
cp -R include/asm-generic /tools/glibc-kernheaders

    Finally, install the cross-platform kernel header files:

    cp -R include/linux /tools/glibc-kernheaders

    Details on this package are located in Section 8.3.2, “Contents of Linux.”

5.08、Glibc-2.3.4-20040701

  • 5.8. Glibc-2.3.4-20040701

    Glibc 包含了主要的C库。这个库提供了基本的 routines，用于分配内存，搜索目录，打开关闭文件，读写文件，字串处理，模式匹配，算法等等。

    大约编译时间: 11.8 SBU

    需要磁盘空间: 800 MB

    Glibc 安装依赖于: Bash, Binutils, Coreutils, Diffutils, Gawk, GCC, Gettext, Grep, Make, Perl, Sed, and Texinfo

    5.8.1. Glibc 的安装

    这个软件包据知，在它的优化选项(包含 -march 和 -mcpu 选项)被改变时，会存在问题。如果任何环境变量重载了预设定义的优化值，比如 CFLAGS 和 CXXFLAGS，在编译 Glibc 时请取消掉它们。

    一个值得注意的地方是，使用不被本书建议的方法来编译 Glibc ，是把系统的稳定性做赌注。

    Glibc 文档推荐在源码目录之外的一个专门的编译目录下进行编译。

    mkdir ../glibc-build
cd ../glibc-build

    下一步，准备编译 Glibc :

5.09、调整工具链

  • 现在临时的C库文件已经装好，接下来本章中要编译的所有工具应该连接到这些库。为了达到这个目标，连接器和编译器的specs文件需要调整。

    在第一遍编译Binutils快结束的时候，已经把连接器调整过了，通过在binutils-build目录下执行以下的命令就可安装：

    make -C ld install

    从现在开始，所有东西都连接到/tools/lib里面的库文件。
    注意

    如果前面第一遍的时候你忽略了保留Binutils源代码和编译目录的提示，就忽略前面的命令。这会有较小的机会导致测试用的一些程序连接到主机的库文件上。这当然不理想，但不是大问题。这种状况在第二遍安装Binutils的时候会被纠正过来。

    现在调整过的连接器已经装好了，Binutils编译目录和源代码目录现在可以删掉了。

    The next task is to amend the GCC specs file so that it points to the new dynamic linker. A simple sed script will accomplish this:

    SPECFILE=`gcc --print-file specs` &&
sed 's@ /lib/ld-linux.so.2@ /tools/lib/ld-linux.so.2@g' /
    $SPECFILE > tempspecfile &&
mv -f tempspecfile $SPECFILE &&
unset SPECFILE

    It is recommended that the above command be copy-and-pasted in order to ensure accuracy. Alternatively, the specs file can be edited by hand. This is done by replacing every occurrence of “/lib/ld-linux.so.2” with “/tools/lib/ld-linux.so.2”

    Be sure to visually inspect the specs file in order to verify the intended changes have been made.

    Important

    If working on a platform where the name of the dynamic linker is something other than ld-linux.so.2, replace “ld-linux.so.2” with the name of the platform's dynamic linker in the above commands. Refer back to Section 5.3, “Toolchain Technical Notes,” if necessary.

    There is a possibility that some include files from the host system have found their way into GCC's private include dir. This can happen as a result of GCC's “fixincludes” process, which runs as part of the GCC build. This is explained in more detail later in this chapter. Run the following command to eliminate this possibility:

    rm -f /tools/lib/gcc/*/*/include/{pthread.h,bits/sigthread.h}

    Caution

    At this point, it is imperative to stop and ensure that the basic functions (compiling and linking) of the new toolchain are working as expected. To perform a sanity check, run the following commands:

    echo 'main(){}' > dummy.c
cc dummy.c
readelf -l a.out | grep ': /tools'

    If everything is working correctly, there should be no errors, and the output of the last command will be of the form:

    [Requesting program interpreter: 
    /tools/lib/ld-linux.so.2]

    Note that /tools/lib appears as the prefix of the dynamic linker.

    If the output is not shown as above or there was no output at all, then something is wrong. Investigate and retrace the steps to find out where the problem is and correct it. This issue must be resolved before continuing on. First, perform the sanity check again, using gcc instead of cc. If this works, then the /tools/bin/cc symlink is missing. Revisit Section 5.5, “GCC-3.4.1 - Pass 1,” and install the symlink. Next, ensure that the PATH is correct. This can be checked by running echo $PATH and verifying that /tools/bin is at the head of the list. If the PATH is wrong it could mean that you are not logged in as user lfs or that something went wrong back in Section 4.4, “Setting Up the Environment.” Another option is that something may have gone wrong with the specs file amendment above. In this case, redo the specs file amendment, being careful to copy-and-paste the commands.

    Once all is well, clean up the test files:

    rm dummy.c a.out

    Now that the temporary C libraries have been installed, all tools compiled in the rest of this chapter should be linked against these libraries. In order to accomplish this, the linker and the compiler's specs file need to be adjusted.

    The linker, adjusted at the end of the first pass of Binutils, is installed by running the following command from within the binutils-build directory:

    make -C ld install

    From this point onwards, everything will link only against the libraries in /tools/lib.

    Note

    If the earlier warning to retain the Binutils source and build directories from the first pass was missed, ignore the above command. This results in a small chance that the subsequent testing programs will link against libraries on the host. This is not ideal, but it is not a major problem. The situation is corrected when the second pass of Binutils is installed later.

    Now that the adjusted linker is installed, the Binutils build and source directories should be removed.

    The next task is to amend the GCC specs file so that it points to the new dynamic linker. A simple sed script will accomplish this:

    SPECFILE=`gcc --print-file specs` &&
sed 's@ /lib/ld-linux.so.2@ /tools/lib/ld-linux.so.2@g' /
    $SPECFILE > tempspecfile &&
mv -f tempspecfile $SPECFILE &&
unset SPECFILE

    It is recommended that the above command be copy-and-pasted in order to ensure accuracy. Alternatively, the specs file can be edited by hand. This is done by replacing every occurrence of “/lib/ld-linux.so.2” with “/tools/lib/ld-linux.so.2”

    Be sure to visually inspect the specs file in order to verify the intended changes have been made.

    Important

    If working on a platform where the name of the dynamic linker is something other than ld-linux.so.2, replace “ld-linux.so.2” with the name of the platform's dynamic linker in the above commands. Refer back to Section 5.3, “Toolchain Technical Notes,” if necessary.

    There is a possibility that some include files from the host system have found their way into GCC's private include dir. This can happen as a result of GCC's “fixincludes” process, which runs as part of the GCC build. This is explained in more detail later in this chapter. Run the following command to eliminate this possibility:

    rm -f /tools/lib/gcc/*/*/include/{pthread.h,bits/sigthread.h}

    Caution

    At this point, it is imperative to stop and ensure that the basic functions (compiling and linking) of the new toolchain are working as expected. To perform a sanity check, run the following commands:

    echo 'main(){}' > dummy.c
cc dummy.c
readelf -l a.out | grep ': /tools'

    If everything is working correctly, there should be no errors, and the output of the last command will be of the form:

    [Requesting program interpreter: 
    /tools/lib/ld-linux.so.2]

    Note that /tools/lib appears as the prefix of the dynamic linker.

    If the output is not shown as above or there was no output at all, then something is wrong. Investigate and retrace the steps to find out where the problem is and correct it. This issue must be resolved before continuing on. First, perform the sanity check again, using gcc instead of cc. If this works, then the /tools/bin/cc symlink is missing. Revisit Section 5.5, “GCC-3.4.1 - Pass 1,” and install the symlink. Next, ensure that the PATH is correct. This can be checked by running echo $PATH and verifying that /tools/bin is at the head of the list. If the PATH is wrong it could mean that you are not logged in as user lfs or that something went wrong back in Section 4.4, “Setting Up the Environment.” Another option is that something may have gone wrong with the specs file amendment above. In this case, redo the specs file amendment, being careful to copy-and-paste the commands.

    Once all is well, clean up the test files:

    rm dummy.c a.out

5.10、Tcl-8.4.7

  • Tcl 软件包包含工具命令语言(Tool Command Language)。

    大约编译时间: 0.9 SBU

    需要磁盘空间: 23 MB

    Tcl 安装依赖于: Bash, Binutils, Coreutils, Diffutils, GCC, Glibc, Grep, Make, and Sed
    5.10.1. Installation of Tcl

    这个软件包和下二个软件包(Expect 和 DejaGNU)被安装是为了支持运行 GCC 和 Binutils 的测试套件。仅

    为了测试目地而安装三个软件包，也许看上去有点过了，但能看到最重要的工具正常的工作,这是非常值得的

    。即使在本章中没有运行测试套件(它们不是主要的), 在第6章运行的测试套件也是需要它

    们的。

    为 Tcl 的编译做准备:

    cd unix
./configure --prefix=/tools

    编译软件包:

    make

    要测试结果，用 TZ=UTC make test。 Tcl 测试套件据知会失败，在还没有完全搞明白的一定的主机条件下

    。因此，测试套件在这里失败不要奇怪，也不要认为很严重。 TZ=UTC 参数设置时区为Coordinated

    Universal Time (UTC)，也就是所谓的格林尼治时间 (GMT)，但是也仅仅是在测试套件运行期间。这将确保

    时钟测试正确。关于 TZ 环境变量的细节参考第7章。

    安装软件包:

    make install


    警告

    不要删除 tcl8.4.7 源码目录，因为下一个软件包将需要它的头文件。

    现在做个必要的符号连接:

    ln -s tclsh8.4 /tools/bin/tclsh

    5.10.2. Tcl 的内容

    安装的程序: tclsh (link to tclsh8.4) and tclsh8.4

    安装的库文件: libtcl8.4.so
    简短描述

    tclsh8.4

    Tcl 命令 shell
    tclsh

    指向 tclsh8.4 的连接
    libtcl8.4.so

    Tcl 库

    --------------------------------------------------------------------------------------
    The Tcl package contains the Tool Command Language.

    Approximate build time: 0.9 SBU

    Required disk space: 23 MB

    Tcl installation depends on: Bash, Binutils, Coreutils, Diffutils, GCC, Glibc, Grep, Make, and Sed
    5.10.1. Installation of Tcl

    This package and the next two (Expect and DejaGNU) are installed to support running the test suites for GCC and Binutils. Installing three packages for testing purposes may seem excessive, but it is very reassuring, if not essential, to know that the most important tools are working properly. Even if the test suites are not run in this chapter (they are not mandatory), these packages are required to run the test suites in Chapter 6.

    Prepare Tcl for compilation:

    cd unix
./configure --prefix=/tools

    Build the package:

    make

    To test the results, issue: TZ=UTC make test. The Tcl test suite is known to experience failures under certain host conditions that are not fully understood. Therefore, test suite failures here are not surprising, and are not considered critical. The TZ=UTC parameter sets the time zone to Coordinated Universal Time (UTC), also known as Greenwich Mean Time (GMT), but only for the duration of the test suite run. This ensures that the clock tests are exercised correctly. Details on the TZ environment variable is provided in Chapter 7.

    Install the package:

    make install


    Warning

    Do not remove the tcl8.4.7 source directory yet, as the next package will need its internal headers.

    Now make a necessary symbolic link:

    ln -s tclsh8.4 /tools/bin/tclsh

    5.10.2. Contents of Tcl

    Installed programs: tclsh (link to tclsh8.4) and tclsh8.4

    Installed library: libtcl8.4.so
    Short Descriptions

    tclsh8.4

    The Tcl command shell
    tclsh

    A link to tclsh8.4
    libtcl8.4.so

    The Tcl library

5.11、Expect-5.42.1

  • Expect 软件包包含一个程序通过执行脚本对话框和其他程序交互。

    大约编译时间: 0.1 SBU

    需要磁盘空间: 3.9 MB

    Expect 安装依赖于: Bash, Binutils, Coreutils, Diffutils, GCC, Glibc, Grep, Make, Sed, and Tcl

    5.11.1. Expect 的安装

    首先，修正一个 bug，在 GCC 测试运行时导致失败:

    patch -Np1 -i ../expect-5.42.1-spawn-1.patch

    现在准备 Expect 编译:

    ./configure --prefix=/tools --with-tcl=/tools/lib --with-x=no

    configure 选项的意义:

  • --with-tcl=/tools/lib

    这将确保 configure 脚本到临时工具安装的位置去找 Tcl，而不是到有可能存在于主系统的那个。

  • --with-x=no

    这告诉 configure 脚本不要搜索 Tk (Tcl的GUI组件) 或者 X 窗口系统库，这两个也许都位于主系统中。

    编译软件包:

    make

    要测试结果，用 make test。 注意，在还没有完全搞明白的一定的主机条件下，Expect 测试套件据知会失败。因此，测试套件在这里失败不要奇怪，也不要认为很严重。

    安装软件包:

    make SCRIPTS="" install

    make 参数的意义:

  • SCRIPTS=""

    这防止 expect 提供的一些脚本的安装，它们并不需要。

    Tcl and Expect 的源码目录现在可以被删除了。

    5.11.2. Expect 的内容

    安装的程序: expect

    安装的库: libexpect-5.42.a

    简短描述

    expect
    通过一个脚本与其它的交互式程序通讯

    libexpect-5.42.a

    包含了些函数，能够让 Expect 作为 Tcl 的扩展使用，或直接被 C 或 C++ 使用(不需要 Tcl)

    ---------------------------------------------------------------------------
    The Expect package contains a program for carrying out scripted dialogues with other interactive programs.

    Approximate build time: 0.1 SBU

    Required disk space: 3.9 MB

    Expect installation depends on: Bash, Binutils, Coreutils, Diffutils, GCC, Glibc, Grep, Make, Sed, and Tcl

    5.11.1. Installation of Expect

    First, fix a bug that can result in false failures during the GCC test suite run:

    patch -Np1 -i ../expect-5.42.1-spawn-1.patch

    Now prepare Expect for compilation:

    ./configure --prefix=/tools --with-tcl=/tools/lib --with-x=no

    The meaning of the configure options:

  • --with-tcl=/tools/lib

    This ensures that the configure script finds the Tcl installation in the temporary tools location instead of possibly locating an existing one on the host system.

  • --with-x=no

    This tells the configure script not to search for Tk (the Tcl GUI component) or the X Window System libraries, both of which may reside on the host system.

    Build the package:

    make

    To test the results, issue: make test. Note that the Expect test suite is known to experience failures under certain host conditions that are not within our control. Therefore, test suite failures here are not surprising and are not considered critical.

    Install the package:

    make SCRIPTS="" install

    The meaning of the make parameter:

  • SCRIPTS=""

    This prevents installation of the supplementary expect scripts, which are not needed.

    The source directories of both Tcl and Expect can now be removed.

    5.11.2. Contents of Expect

    Installed program: expect

    Installed library: libexpect-5.42.a

    Short Descriptions

    expect
    Communicates with other interactive programs according to a script

    libexpect-5.42.a

    Contains functions that allow Expect to be used as a Tcl extension or to be used directly from C or C++ (without Tcl)

5.12、DejaGNU-1.4.4

  • 5.12. DejaGNU-1.4.4

    DejaGNU 软件包包含了一个测试其它程序的框架。

    大约编译时间: 0.1 SBU

    需要磁盘空间: 8.6 MB

    DejaGNU 安装依赖于: Bash, Binutils,Coreutils, Diffutils, GCC, Glibc, Grep, Make, and Sed

    5.12.1. DejaGNU 的安装

    DejaGNU 准备编译: 

    ./configure --prefix=/tools

    编译和安装软件包: 

    make install

     

    5.12.2. DejaGNU 的内容

    安装的程序: runtest

    简短描述

     

    runtest

    一个外包脚本，用来找到正确的 expect 脚本然后运行 DejaGNU

    ---------------------------------------------------------------------------

    5.12. DejaGNU-1.4.4

    The DejaGNU package contains a framework for testing other programs.

    Approximate build time: 0.1 SBU

    Required disk space: 8.6 MB

    DejaGNU installation depends on: Bash, Binutils,Coreutils, Diffutils, GCC, Glibc, Grep, Make, and Sed

    5.12.1. Installation of DejaGNU

    Prepare DejaGNU for compilation: 

    ./configure --prefix=/tools

    Build and install the package: 

    make install

     

    5.12.2. Contents of DejaGNU

    Installed program: runtest

    Short Descriptions

     

    runtest

    A wrapper script that locates the proper expect shell and then runs DejaGNU

5.13. GCC-3.4.1 - Pass 2

  • Approximate build time: 11.0 SBU

    Required disk space: 274 MB

    GCC installation depends on: Bash, Binutils, Coreutils,
    Diffutils, Findutils, Gawk, Gettext, Glibc, Grep, Make, Perl,
    Sed, and Texinfo

    5.13.1. Re-installation of GCC

    This package is known to have issues when its default optimization
    flags (including the -march and
    -mcpu options) are changed. If
    any environment variables that override default optimizations have
    been defined, such as CFLAGS and CXXFLAGS, unset them when building GCC.

    The tools required to test GCC and Binutils—Tcl, Expect and
    DejaGNU—are installed now. GCC and Binutils can now be
    rebuilt, linking them against the new Glibc and testing them
    properly (if running the test suites in this chapter). Please note
    that these test suites are highly dependent on properly functioning
    PTYs which are provided by the host. PTYs are most commonly
    implemented via the devpts file system.
    Check to see if the host system is set up correctly in this regard
    by performing a quick test: 

    expect -c "spawn ls"

    The response might be: 

    The system has no more ptys.  
Ask your system administrator to create more.

    If the above message is received, the host does not have its PTYs
    set up properly. In this case, there is no point in running the
    test suites for GCC and Binutils until this issue is resolved.
    Please consult the LFS Wiki at http://wiki.linuxfromscratch.org/
    for more information on how to get PTYs working.

    Because the C and the C++ compilers will be built, unpack both the
    core and the g++ tarballs (as well as test suite, if you want to
    run the tests). By unpacking them in the working directory, they
    will all unfold into a single gcc-3.4.1/
    subdirectory.

    First correct a known problem and make an essential adjustment: 

    patch -Np1 -i ../gcc-3.4.1-no_fixincludes-1.patch
patch -Np1 -i ../gcc-3.4.1-specs-1.patch

    The first patch disables the GCC fixincludes script. This was briefly mentioned
    earlier, but a more in-depth explanation of the fixincludes process
    is warranted here. Under normal circumstances, the GCC
    fixincludes script scans the
    system for header files that need to be fixed. It might find that
    some Glibc header files on the host system need to be fixed, and
    will fix them and put them in the GCC private include directory. In
    Chapter 6, after the
    newer Glibc has been installed, this private include directory will
    be searched before the system include directory. This may result in
    GCC finding the fixed headers from the host system, which most
    likely will not match the Glibc version used for the LFS system.

    The second patch changes GCC's default location of the dynamic
    linker (typically ld-linux.so.2). It also
    removes /usr/include from GCC's include
    search path. Patching now rather than adjusting the specs file
    after installation ensures that the new dynamic linker is used
    during the actual build of GCC. That is, all of the final (and
    temporary) binaries created during the build will link against the
    new Glibc.

    [Important]

     

    Important

    The above patches are critical in ensuring a successful overall
    build. Do not forget to apply them.

    Create a separate build directory again: 

    mkdir ../gcc-build
cd ../gcc-build

    Before starting to build GCC, remember to unset any environment
    variables that override the default optimization flags.

    Now prepare GCC for compilation: 

    ../gcc-3.4.1/configure --prefix=/tools /
    --libexecdir=/tools/lib --with-local-prefix=/tools /
    --enable-clocale=gnu --enable-shared /
    --enable-threads=posix --enable-__cxa_atexit /
    --enable-languages=c,c++ --disable-libstdcxx-pch

    The meaning of the new configure options:

    --enable-clocale=gnu

     

     

    This option ensures the correct locale model is selected for
    the C++ libraries under all circumstances. If the configure
    script finds the de_DE
    locale installed, it will select the correct gnu locale
    model. However, if the de_DE locale is not installed,
    there is the risk of building Application Binary Interface
    (ABI)-incompatible C++ libraries because the incorrect
    generic locale model may be selected.

     

     

    --enable-threads=posix

    This enables C++ exception handling for multi-threaded code.

     

    --enable-__cxa_atexit

    This option allows use of __cxa_atexit, rather than
    atexit, to register
    C++ destructors for local statics and global objects. This
    option is essential for fully standards-compliant handling of
    destructors. It also effects the C++ ABI, and therefore
    results in C++ shared libraries and C++ programs that are
    interoperable with other Linux distributions.

     

     

    --enable-languages=c,c++

    This option ensures that both the C and C++ compilers are
    built.

     

    --disable-libstdcxx-pch

    Do not build the pre-compiled header (PCH) for libstdc++. It takes up a lot of space, and we
    have no use for it.

     

    Compile the package: 

    make

    There is no need to use the bootstrap target now because the compiler
    being used to compile this GCC was built from the exact same
    version of the GCC sources used earlier.

    Compilation is now complete. As previously mentioned, running the
    test suites for the temporary tools compiled in this chapter is not
    mandatory. To run the GCC test suite anyway, use the following
    command: 

    make -k check

    The -k flag is used to make the
    test suite run through to completion and not stop at the first
    failure. The GCC test suite is very comprehensive and is almost
    guaranteed to generate a few failures. To receive a summary of the
    test suite results, run: 

    ../gcc-3.4.1/contrib/test_summary

    For only the summaries, pipe the output through grep -A7 Summ.

    Results can be compared to those posted to the gcc-testresults
    mailing list to see similar configurations to the one being built.
    For an example of how current GCC-3.4.1 should look on
    i686-pc-linux-gnu, see http://gcc.gnu.org/ml/gcc-testresults/2004-07/msg00179.html.

    A few unexpected failures cannot always be avoided. The GCC
    developers are usually aware of these issues, but have not resolved
    them yet. Unless the test results are vastly different from those
    at the above URL, it is safe to continue.

    Install the package: 

    make install
    [Note]

     

    Note

    At this point it is strongly recommended to repeat the sanity
    check we performed earlier in this chapter. Refer back to
    Section 5.9,
    “Adjusting the Toolchain,”     and repeat the test
    compilation. If the result is wrong, the most likely reason is
    that the GCC Specs patch was not properly applied.

    Details on this package are located in Section 6.14.2, “Contents
    of GCC.”

5.14. Binutils-2.15.91.0.2 - Pass 2

  • Binutils 是一组开发工具，包括连接器，汇编器和其他用于处理目标文件和档案的工具。

    预计编译时间: 1.5 SBU

    需要磁盘空间: 108 MB

    Binutils 安装依赖: Bash, Coreutils,
    Diffutils, GCC, Gettext, Glibc, Grep, Make, Perl, Sed, and
    Texinfo

    5.14.1. 安装 Binutils

    如果你改变这个包缺省的优化参数(包括 -march和-mcpu),会有不好的表现.
    所以,如果你自己定义了某些环境变量,比如CFLAGS and CXXFLAGS, 最好在
    编译 Binutils 的时候 unset 或者修改他们.

    为编译创建一个单独目录: 

    mkdir ../binutils-build
cd ../binutils-build

    编译配置准备: 

    ../binutils-2.15.91.0.2/configure --prefix=/tools /
    --enable-shared --with-lib-path=/tools/lib

    配置参数的意思:

    --with-lib-path=/tools/lib

     

     

    这个参数告诉configure脚本,指定了编译的时候的库文件路径 /tools/lib 给连接器.
    This prevents the linker from searching through
    library directories on the host.

    编译软件包: 

    make

    编译完成了. 也如前面说的, 在这一章节里面,编译测试不是一定要的.
    总之,编译测试就使用下面命令: 

    make check

    软件包安装: 

    make install

    现在，为后面的"Re-adjusting"准备连接器脚本: 

    make -C ld clean
make -C ld LIB_PATH=/usr/lib:/lib
    [Warning]

     

    注意

    不要 删除
    Binutils 代码和编译准备的文件夹. 在后面的章节里面还会用到这些东西

    The Binutils package contains a linker, an assembler, and other
    tools for handling object files.

    Approximate build time: 1.5 SBU

    Required disk space: 108 MB

    Binutils installation depends on: Bash, Coreutils,
    Diffutils, GCC, Gettext, Glibc, Grep, Make, Perl, Sed, and
    Texinfo

    5.14.1. Re-installation of Binutils

    This package is known to have issues when its default optimization
    flags (including the -march and
    -mcpu options) are changed. If
    any environment variables that override default optimizations have
    been defined, such as CFLAGS and CXXFLAGS, unset them when building Binutils.

    Create a separate build directory again: 

    mkdir ../binutils-build
cd ../binutils-build

    Prepare Binutils for compilation: 

    ../binutils-2.15.91.0.2/configure --prefix=/tools /
    --enable-shared --with-lib-path=/tools/lib

    The meaning of the new configure option:

    --with-lib-path=/tools/lib

     

     

    This tells the configure script to specify the library search
    path during the compilation of Binutils, resulting in
    /tools/lib being passed to the
    linker. This prevents the linker from searching through
    library directories on the host.

    Compile the package: 

    make

    Compilation is now complete. As discussed earlier, running the test
    suite is not mandatory for the temporary tools here in this
    chapter. To run the Binutils test suite anyway, issue the following
    command: 

    make check

    Install the package: 

    make install

    Now prepare the linker for the “Re-adjusting” phase in the next chapter: 

    make -C ld clean
make -C ld LIB_PATH=/usr/lib:/lib
    [Warning]

     

    Warning

    Do not remove the
    Binutils source and build directories yet. These directories
    will be needed again in the next chapter in their current
    state.

5.15. Gawk-3.1.4

  • Gawk软件包含有用于管理文本文件的程序。

    预计安装时间： 0.2 SBU

    所需硬盘空间： 17 MB

    Gawk安装依赖于： Bash, Binutils, Coreutils,
    Diffutils, GCC, Gettext, Glibc, Grep, Make, 和 Sed

    5.15.1. 安装Gawk

    准备编译Gawk： 

    ./configure --prefix=/tools

    编译软件包： 

    make

    测试结果(此行为非必要)：make check.

    安装软件包： 

    make install

    更多关于软件包的资料在 Section 6.20.2,
    “Contents of Gawk.”

    ---------------------------------------------------------------------------------------------------------------------------

    The Gawk package contains programs for manipulating text files.

    Approximate build time: 0.2 SBU

    Required disk space: 17 MB

    Gawk installation depends on: Bash, Binutils, Coreutils,
    Diffutils, GCC, Gettext, Glibc, Grep, Make, and Sed

    5.15.1. Installation of Gawk

    Prepare Gawk for compilation: 

    ./configure --prefix=/tools

    Compile the package: 

    make

    To test the results (not necessary), issue: make check.

    Install the package: 

    make install

    Details on this package are located in Section 6.20.2,
    “Contents of Gawk.”

5.16. Coreutils-5.2.1

  • Coreutils软件包含有用于展示和设置基本系统特性的工具。

    预计安装时间： 0.9 SBU

    所需硬盘空间： 69 MB

    coreutils安装依赖于： Bash, Binutils,
    Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make, Perl, 和
    Sed

    5.16.1. 安装coreutils

    准备编译Coreutils 

    DEFAULT_POSIX2_VERSION=199209 ./configure --prefix=/tools

    倘若用版本高于2.3.2的 Glibc 来编译此包的话，可能会出现问题。 Coreutil中的一些工具(像 head, tail, 和 sort)将不会接受这种已经被人们用了近30年了的传统语法。 这种老式的语法太普及了，以至于兼容性问题将一直存在，直到那些仍使用老式语法的地方得到更新。在上面的命令中，我们通过将环境变量 DEFAULT_POSIX2_VERSION 设置为“199209”来获得兼容性。如果你不想让 coreutils 和传统语法兼容，那么就不要设置环境变量 DEFAULT_POSIX2_VERSION 了。不过记住了！如果你这样做的话，将会导致一些额外的后续工作，其中包括给许多仍在使用老式语法的软件包打补丁。因此，建议你能够严格的按照以上指示键入命令。

    编译软件包： 

    make

    测试结果：make
    RUN_EXPENSIVE_TESTS=yes check    。参数 RUN_EXPENSIVE_TESTS=yes 让测试程序执行一些附加测试。在某些平台上，这些测试会耗费相对更多的CPU和内存。不过，基本上linux不会有这种问题啦。

    安装软件包： 

    make install

    更多关于软件包的资料在 Section 6.15.2,
    “Contents of Coreutils.”

    ---------------------------------------------------------------------------------------------------------------------------
    The Coreutils package contains utilities for showing and setting
    the basic system characteristics.

    Approximate build time: 0.9 SBU

    Required disk space: 69 MB

    Coreutils installation depends on: Bash, Binutils,
    Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make, Perl, and
    Sed

    5.16.1. Installation of Coreutils

    Prepare Coreutils for compilation: 

    DEFAULT_POSIX2_VERSION=199209 ./configure --prefix=/tools

    This package has an issue when compiled against versions of Glibc
    later than 2.3.2. Some of the Coreutils utilities (such as
    head, tail, and sort) will reject their traditional syntax, a
    syntax that has been in use for approximately 30 years. This old
    syntax is so pervasive that compatibility should be preserved until
    the many places where it is used can be updated. Backwards
    compatibility is achieved by setting the DEFAULT_POSIX2_VERSION environment variable to
    “199209” in the above
    command. If you do not want Coreutils to be backwards compatible
    with the traditional syntax, then omit setting the DEFAULT_POSIX2_VERSION environment variable. It is
    important to remember that doing so will have consequences,
    including the need to patch the many packages that still use the
    old syntax. Therefore, it is recommended that the instructions be
    followed exactly as given above.

    Compile the package: 

    make

    To test the results, issue: make
    RUN_EXPENSIVE_TESTS=yes check    . The RUN_EXPENSIVE_TESTS=yes parameter tells
    the test suite to run several additional tests that are considered
    relatively expensive (in terms of CPU power and memory usage) on
    some platforms, but generally are not a problem on Linux.

    Install the package: 

    make install

    Details on this package are located in Section 6.15.2,
    “Contents of Coreutils.”

5.17. Bzip2-1.0.2

  • Bzip2 软件包含有压缩和解压的程序。对文本文件来说，能得到比传统的 gzip 格式高得多的压缩比。

    预计编译时间： 0.1 SBU

    所需硬盘空间： 2.5 MB

    Bzip2 安装依赖于： Bash, Binutils, Coreutils,
    Diffutils, GCC, Glibc, 和 Make

    5.17.1. 安装 Bzip2

    Bzip2 软件包没有 configure 脚本。用下列命令编译： 

    make

    安装软件包： 

    make PREFIX=/tools install

    本软件包的详细内容可在  6.40.2
    “Bzip2 的内容”     中找到。

    ---------------------------------------------------------------------------------------------------------------------------

    The Bzip2 package contains programs for compressing and
    decompressing files. Text files yield a much better compression
    than with the traditional gzip.

    Approximate build time: 0.1 SBU

    Required disk space: 2.5 MB

    Bzip2 installation depends on: Bash, Binutils, Coreutils,
    Diffutils, GCC, Glibc, and Make

    5.17.1. Installation of Bzip2

    The Bzip2 package does not contain a configure script. Compile it with: 

    make

    Install the package: 

    make PREFIX=/tools install

    Details on this package are located in Section 6.40.2,
    “Contents of Bzip2.”

5.18. Gzip-1.3.5

  • Gzip 软件包含有用于压缩和解压文件的程序。

    预计编译时间： 0.1 SBU

    所需硬盘空间： 2.6 MB

    Gzip 安装依赖于： Bash, Binutils, Coreutils,
    Diffutils, GCC, Glibc, Grep, Make, 和 Sed

    5.18.1. 安装 Gzip

    为编译 Gzip 做准备： 

    ./configure --prefix=/tools

    编译软件包： 

    make

    本软件包没有测试套件。

    安装软件包： 

    make install

    本软件包的详细内容可在 Section 6.46.2,
    “Gzip 的内容”     中找到。

    -----------------------------------------------------------------------------------------------------------------

    The Gzip package contains programs for compressing and
    decompressing files.

    Approximate build time: 0.1 SBU

    Required disk space: 2.6 MB

    Gzip installation depends on: Bash, Binutils, Coreutils,
    Diffutils, GCC, Glibc, Grep, Make, and Sed

    5.18.1. Installation of Gzip

    Prepare Gzip for compilation: 

    ./configure --prefix=/tools

    Compile the package: 

    make

    This package does not come with a test suite.

    Install the package: 

    make install

    Details on this package are located in Section 6.46.2,
    “Contents of Gzip.”

5.19. Diffutils-2.8.1

  • Diffutils 用来比较文件之间或目录之间内容的差异。

    预计编译时间： 0.1 SBU

    所需硬盘空间： 7.5 MB

    Diffutils 安装依赖于： Bash, Binutils,
    Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make, 和 Sed

    5.19.1. 安装 Diffutils

    为编译 Diffutils 做准备： 

    ./configure --prefix=/tools

    编译软件包： 

    make

    本软件包没有测试套件。

    安装软件包： 

    make install

    本软件包的详细内容在  6.41.2,
    “Diffutils 的内容”     一节中可找到。

    -------------------------------------------------------------------------------------------------------------------------------------

    The Diffutils package contains programs that show the differences
    between files or directories.

    Approximate build time: 0.1 SBU

    Required disk space: 7.5 MB

    Diffutils installation depends on: Bash, Binutils,
    Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make, and Sed

    5.19.1. Installation of Diffutils

    Prepare Diffutils for compilation: 

    ./configure --prefix=/tools

    Compile the package: 

    make

    This package does not come with a test suite.

    Install the package: 

    make install

    Details on this package are located in Section 6.41.2,
    “Contents of Diffutils.”

5.20. Findutils-4.1.20

  • Findutils 软件包含有查找文件的程序，可以递归地搜索目录树，也可以创建、维护和搜索一个数据库(通常比直接搜索目录树快，但如果数据库近期未更新，则得到的结果不可靠)。

    预计编译时间： 0.2 SBU

    所需硬盘空间： 7.6 MB

    Findutils 安装依赖于： Bash, Binutils,
    Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make 和 Sed

    5.20.1. 安装 Findutils

    为编译 Findutils 做准备： 

    ./configure --prefix=/tools

    编译软件包： 

    make

    测试结果，运行：make
    check    .

    安装软件包： 

    make install

    本软件包的内容在  6.19.2,
    “Findutils 的内容”     一节中可找到。

    ----------------------------------------------------------------------------------------------------------------------------------------------

    The Findutils package contains programs to find files. Processes
    are provided to recursively search through a directory tree and to
    create, maintain, and search a database (often faster than the
    recursive find, but unreliable if the database has not been
    recently updated).

    Approximate build time: 0.2 SBU

    Required disk space: 7.6 MB

    Findutils installation depends on: Bash, Binutils,
    Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make and Sed

    5.20.1. Installation of Findutils

    Prepare Findutils for compilation: 

    ./configure --prefix=/tools

    Compile the package: 

    make

    To test the results, issue: make
    check    .

    Install the package: 

    make install

    Details on this package are located in Section 6.19.2,
    “Contents of Findutils.”

5.21. Make-3.80

  • Make 软件包含有一个编译大型软件包的程序。

    预计编译时间： 0.2 SBU

    所需硬盘空间： 8.8 MB

    Make 安装依赖于： Bash, Binutils, Coreutils,
    Diffutils, GCC, Gettext, Glibc, Grep, 和 Sed

    5.21.1. 安装 Make

    为编译 Make 做准备： 

    ./configure --prefix=/tools

    编译软件包： 

    make

    测试结果，运行：make
    check    .

    安装软件包： 

    make install

    本软件包的详细内容在  6.48.2,
    “Make的内容”    一节中可以找到。

    -------------------------------------------------------------------------------------------------------------------------------------------

    The Make package contains a program for compiling large packages.

    Approximate build time: 0.2 SBU

    Required disk space: 8.8 MB

    Make installation depends on: Bash, Binutils, Coreutils,
    Diffutils, GCC, Gettext, Glibc, Grep, and Sed

    5.21.1. Installation of Make

    Prepare Make for compilation: 

    ./configure --prefix=/tools

    Compile the package: 

    make

    To test the results, issue: make
    check    .

    Install the package: 

    make install

    Details on this package are located in Section 6.48.2,
    “Contents of Make.”

5.22. Grep-2.5.1

  • Grep 软件包含有在多文件中搜索的程序。

    预计编译时间： 0.1 SBU

    所需硬盘空间： 5.8 MB

    Grep 安装依赖于： Bash, Binutils, Coreutils,
    Diffutils, GCC, Gettext, Glibc, Make, Sed, 和 Texinfo

    5.22.1. 安装 Grep

    为编译 Grep 做准备： 

    ./configure --prefix=/tools /
    --disable-perl-regexp --with-included-regex

    配置参数的的意思是：

    --disable-perl-regexp

     

    本参数确保 grep 程序不连接到 Perl 兼容正则表达式 (PCRE) 库上，因为主系统可能有这个库，但如果进入 chroot 环境，就不能使用了。

    --with-included-regex

     

     

    确保 Grep 使用内建的正则表达式代码。没有本选项，Grep 会使用 Glibc 中的代码，而那些代码是漏洞百出的。

    编译软件包： 

    make

    测试结果，运行： make
    check    .

    安装软件包： 

    make install

    本软件包的详细内容可在  6.44.2,
    “Grep 的内容”    一节中找到。

    -------------------------------------------------------------------------------------------------------------------------------

    The Grep package contains programs for searching through files.

    Approximate build time: 0.1 SBU

    Required disk space: 5.8 MB

    Grep installation depends on: Bash, Binutils, Coreutils,
    Diffutils, GCC, Gettext, Glibc, Make, Sed, and Texinfo

    5.22.1. Installation of Grep

    Prepare Grep for compilation: 

    ./configure --prefix=/tools /
    --disable-perl-regexp --with-included-regex

    The meaning of the configure options:

    --disable-perl-regexp

     

    This makes sure that the grep program does not get linked against
    a Perl Compatible Regular Expression (PCRE) library that may
    be present on the host and would not be available once we
    enter the chroot environment.

    --with-included-regex

     

     

    This ensures that Grep uses its internal regular expression
    code. Without this switch, Grep will use the code from Glibc,
    which is known to be buggy.

    Compile the package: 

    make

    To test the results, issue: make
    check    .

    Install the package: 

    make install

    Details on this package are located in Section 6.44.2,
    “Contents of Grep.”

5.23. Sed-4.1.2

  • Sed 软件包 包含 一个 流编辑器 程序.

    预计 编译 时间: 0.2 SBU

    需要 磁盘 空间: 5.2 MB

    Sed 安装 依赖: Bash, Binutils, Coreutils,
    Diffutils, GCC, Gettext, Glibc, Grep, Make, and Texinfo

    5.23.1. Sed 的安装

    Sed 编译 配置 准备 : 

    ./configure --prefix=/tools

    编译 软件包: 

    make

    测试编译结果 , 使用命令: make
    check    .

    安装 软件包: 

    make install

    更多关于软件包的资料在 Section 6.28.2, “Contents
    of Sed.”

    The Sed package contains a stream editor.

    Approximate build time: 0.2 SBU

    Required disk space: 5.2 MB

    Sed installation depends on: Bash, Binutils, Coreutils,
    Diffutils, GCC, Gettext, Glibc, Grep, Make, and Texinfo

    5.23.1. Installation of Sed

    Prepare Sed for compilation: 

    ./configure --prefix=/tools

    Compile the package: 

    make

    To test the results, issue: make
    check    .

    Install the package: 

    make install

    Details on this package are located in Section 6.28.2, “Contents
    of Sed.”

5.24. Gettext-0.14.1

  • Gettext 软件包包含国际化和本地化工具。它们能使程序以支持本地语言的方式编译，按使用者的母语，输出相应的信息。

    预计编译时间： 0.5 SBU

    所需硬盘空间： 55 MB

    Gettext 安装依赖于： Bash, Binutils, Bison,
    Coreutils, Diffutils, Gawk, GCC, Glibc, Grep, Make, 和 Sed

    5.24.1. 安装 Gettext

    为编译 Gettext 做准备： 

    ./configure --prefix=/tools --disable-libasprintf /
    --disable-csharp

    配置参数的意思是：

    --disable-libasprintf

     

    本参数告诉 Gettext 不编译 asprintf 库。因为本章和下一章的软件包都不需要它，并且 Gettext 随后会重新编译，这样可以节约时间和空间。

    --disable-csharp

     

     

    本参数告诉 Gettext 不使用 C# 编译器，即使主系统上安装了某个 C# 编译器。 这是因为一旦我们进入 chroot 环境，C# 就不可使用了。

    编译软件包： 

    make

    测试结果，运行： make
    check     . 运行时间颇长，约 7 SBU. Gettext 的测试套件在某些宿主环境下总是会出错的，比如主系统里安装了 Java 编译器。关闭 Java 的实验性补丁可以在 LFS 补丁项目找到： http://www.linuxfromscratch.org/patches/.

    安装软件包： 

    make install

    本软件包的详细内容在  6.30.2,
    “Gettext 的内容”一节中可以找到。

    ----------------------------------------------------------------------------------------------------------------------------------------

    The Gettext package contains utilities for internationalization and
    localization. These allow programs to be compiled with NLS,
    enabling them to output messages in the user's native language.

    Approximate build time: 0.5 SBU

    Required disk space: 55 MB

    Gettext installation depends on: Bash, Binutils, Bison,
    Coreutils, Diffutils, Gawk, GCC, Glibc, Grep, Make, and Sed

    5.24.1. Installation of Gettext

    Prepare Gettext for compilation: 

    ./configure --prefix=/tools --disable-libasprintf /
    --disable-csharp

    The meaning of the configure options:

    --disable-libasprintf

     

    This flag tells Gettext not to build the asprintf library. Because nothing in this
    chapter or the next requires this library and Gettext gets
    rebuilt later, exclude it to save time and space.

    --disable-csharp

     

     

    This tells Gettext not to use a C# compiler, even if a C#
    compiler is installed on the host. This needs to be done
    because once we enter the chroot environment, C# will no
    longer be available.

    Compile the package: 

    make

    To test the results, issue: make
    check    . This takes quite some time, around 7 SBUs. The
    Gettext test suite is known to experience failures under certain
    host conditions, for example when it finds a Java compiler on the
    host. An experimental patch to disable Java is available from the
    LFS Patches project at http://www.linuxfromscratch.org/patches/.

    Install the package: 

    make install

    Details on this package are located in Section 6.30.2,
    “Contents of Gettext.”

5.25. Ncurses-5.4

  • Ncurses 软件包含有字符屏幕的终端无关支持库。

    预计编译时间： 0.7 SBU

    所需硬盘空间： 26 MB

    Ncurses 安装依赖于： Bash, Binutils,
    Coreutils, Diffutils, Gawk, GCC, Glibc, Grep, Make, 和 Sed

    5.25.1. 安装 Ncurses

    为编译 Ncurses 做准备： 

    ./configure --prefix=/tools --with-shared /
    --without-debug --without-ada --enable-overwrite

    配置参数的意思是：

    --without-ada

     

    本参数告诉 Ncurses 不编译 Ada 扩展，即使主系统里安装了某个 Ada 编译器。这是因为一旦进入 chroot 环境，Ada 就不可使用了。

    --enable-overwrite

    本参数告诉 Ncurses 把头文件安装到 /tools/include ，而不是默认的 /tools/include/ncurses，以确保其他软件包能顺利找到 Ncurses 库的头文件。

    编译软件包： 

    make

    本软件包没有附带测试套件。

    Install the package:

    安装软件包：

     

    make install

    本软件包的详细内容在  6.21.2,
    “Ncurses 的内容”一节中可以找到。

    --------------------------------------------------------------------------------------------------------------------------------------------

    The Ncurses package contains libraries for terminal-independent
    handling of character screens.

    Approximate build time: 0.7 SBU

    Required disk space: 26 MB

    Ncurses installation depends on: Bash, Binutils,
    Coreutils, Diffutils, Gawk, GCC, Glibc, Grep, Make, and Sed

    5.25.1. Installation of Ncurses

    Prepare Ncurses for compilation: 

    ./configure --prefix=/tools --with-shared /
    --without-debug --without-ada --enable-overwrite

    The meaning of the configure options:

    --without-ada

     

    This tells Ncurses not to build its Ada bindings, even if an
    Ada compiler is installed on the host. This needs to be done
    because once we enter the chroot environment, Ada will no
    longer be available.

    --enable-overwrite

    This tells Ncurses to install its header files into
    /tools/include, instead of
    /tools/include/ncurses, to ensure
    that other packages can find the Ncurses headers
    successfully.

    Compile the package: 

    make

    This package does not come with a test suite.

    Install the package: 

    make install

    Details on this package are located in Section 6.21.2,
    “Contents of Ncurses.”

5.26. Patch-2.5.4

  • Patch 软件包 包含 文件修补程序.

    预计 编译 时间: 0.1 SBU

    需要 磁盘 空间: 1.9 MB

    Patch 安装 依赖: Bash, Binutils, Coreutils,
    Diffutils, GCC, Glibc, Grep, Make, and Sed

    5.26.1. Patch的安装

    Patch编译配置准备 : 

    CPPFLAGS=-D_GNU_SOURCE ./configure --prefix=/tools

    编译 预处理 标志-D_GNU_SOURCE 只有PowerPC 平台
    才必需要. 其他平台可以不写.

    编译 软件包: 

    make

    这个软件包没有编译测试.

    软件包 安装: 

    make install

    更多关于软件包的资料在 Section 6.50.2,
    “Contents of Patch.”

    The Patch package contains a program for modifying files.

    Approximate build time: 0.1 SBU

    Required disk space: 1.9 MB

    Patch installation depends on: Bash, Binutils, Coreutils,
    Diffutils, GCC, Glibc, Grep, Make, and Sed

    5.26.1. Installation of Patch

    Prepare Patch for compilation: 

    CPPFLAGS=-D_GNU_SOURCE ./configure --prefix=/tools

    The preprocessor flag -D_GNU_SOURCE is only needed on the
    PowerPC platform. It can be left out on other architectures.

    Compile the package: 

    make

    This package does not come with a test suite.

    Install the package: 

    make install

    Details on this package are located in Section 6.50.2,
    “Contents of Patch.”

5.27. Tar-1.14

  • Tar 软件包 包含 归档压缩 程序.

    预计 编译 时间: 0.2 SBU

    需要 磁盘 空间: 10 MB

    Tar 安装 依赖: Bash, Binutils, Coreutils,
    Diffutils, GCC, Gettext, Glibc, Grep, Make, and Sed

    5.27.1. Tar 的安装

    Tar 编译配置准备: 

    ./configure --prefix=/tools

    编译 软件包: 

    make

    测试 编译 结果, 使用命令: make
    check    .

    软件包的安装: 

    make install

    关于软件包的更多资料 在 Section 6.56.2, “Contents
    of Tar.”

    The Tar package contains an archiving program.

    Approximate build time: 0.2 SBU

    Required disk space: 10 MB

    Tar installation depends on: Bash, Binutils, Coreutils,
    Diffutils, GCC, Gettext, Glibc, Grep, Make, and Sed

    5.27.1. Installation of Tar

    Prepare Tar for compilation: 

    ./configure --prefix=/tools

    Compile the package: 

    make

    To test the results, issue: make
    check    .

    Install the package: 

    make install

    Details on this package are located in Section 6.56.2, “Contents
    of Tar.”

5.28. Texinfo-4.7

  • Texinfo 软件包含有读、写和转换 Info 文档的程序。

    预计编译时间： 0.2 SBU

    所需硬盘空间： 16 MB

    Texinfo 安装依赖于： Bash, Binutils,
    Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make, Ncurses,
    和 Sed

    5.28.1. 安装 Texinfo

    为编译 Texinfo 做准备： 

    ./configure --prefix=/tools

    编译软件包： 

    make

    测试结果，执行：make
    check    .

    安装软件包： 

    make install

    本软件包的详细内容在  6.34.2,
    “Texinfo 的内容”     一节中可以找到。

    ------------------------------------------------------------------------------------------------------------------------

    The Texinfo package contains programs for reading, writing, and
    converting Info documents.

    Approximate build time: 0.2 SBU

    Required disk space: 16 MB

    Texinfo installation depends on: Bash, Binutils,
    Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make, Ncurses,
    and Sed

    5.28.1. Installation of Texinfo

    Prepare Texinfo for compilation: 

    ./configure --prefix=/tools

    Compile the package: 

    make

    To test the results, issue: make
    check    .

    Install the package: 

    make install

    Details on this package are located in Section 6.34.2,
    “Contents of Texinfo.”

5.29. Bash-3.0

  • Bash 软件包 包含了 Bourne-Again SHell.

    预计编译时间: 1.2 SBU

    需要磁盘空间: 27 MB

    Bash 安装依赖的关联: Binutils, Coreutils,
    Diffutils, Gawk, GCC, Glibc, Grep, Make, Ncurses, and Sed.

    5.29.1. Bash的安装

    Bash编译配置准备: 

    ./configure --prefix=/tools --without-bash-malloc

    配置选项的说明:

    --without-bash-malloc

     

    这个选项禁用了Bash的内存分配(malloc)函数,此函数会引起段错误.
    关闭这个选项，Bash就会使用Glibc的malloc函数，变得更稳定.

    编译软件包: 

    make

    测试编译结果, 使用命令: make
    tests    .

    安装软件包: 

    make install

    给终端做个链接sh: 

    ln -s bash /tools/bin/sh

    更多关于这个软件包的资料在 6.37.2章节,
    “Contents of Bash.”

    The Bash package contains the Bourne-Again SHell.

    Approximate build time: 1.2 SBU

    Required disk space: 27 MB

    Bash installation depends on: Binutils, Coreutils,
    Diffutils, Gawk, GCC, Glibc, Grep, Make, Ncurses, and Sed.

    5.29.1. Installation of Bash

    Prepare Bash for compilation: 

    ./configure --prefix=/tools --without-bash-malloc

    The meaning of the configure option:

    --without-bash-malloc

     

    This options turns off the use of Bash's memory allocation
    (malloc) function which is known to cause segmentation
    faults. By turning this option off, Bash will use the malloc
    functions from Glibc which are more stable.

    Compile the package: 

    make

    To test the results, issue: make
    tests    .

    Install the package: 

    make install

    Make a link for the programs that use sh for a shell: 

    ln -s bash /tools/bin/sh

    Details on this package are located in Section 6.37.2,
    “Contents of Bash.”

5.30. M4-1.4.2

  • M4 软件包含有一个宏处理器。

    预计编译时间： 0.1 SBU

    所需硬盘空间： 3.0 MB

    M4 安装依赖于： Bash, Binutils, Coreutils,
    Diffutils, GCC, Gettext, Glibc, Grep, Make, Perl, 和 Sed

    5.30.1. 安装 M4

    为编译 M4 做准备： 

    ./configure --prefix=/tools

    编译软件包： 

    make

    测试结果，执行：make
    check    .

    安装软件包： 

    make install

    本软件包的详细内容在　 6.24.2, “M4　的内容”一节中可以找到。

    ----------------------------------------------------------------------------------------------------------------------------------------

    The M4 package contains a macro processor.

    Approximate build time: 0.1 SBU

    Required disk space: 3.0 MB

    M4 installation depends on: Bash, Binutils, Coreutils,
    Diffutils, GCC, Gettext, Glibc, Grep, Make, Perl, and Sed

    5.30.1. Installation of M4

    Prepare M4 for compilation: 

    ./configure --prefix=/tools

    Compile the package: 

    make

    To test the results, issue: make
    check    .

    Install the package: 

    make install

    Details on this package are located in Section 6.24.2, “Contents
    of M4.”

5.31. Bison-1.875a

  • Bison 软件包含有一个语法分析程序生成器。

    预计编译时间： 0.6 SBU

    所需硬盘空间： 10.6 MB

    Bison 安装依赖于： Bash, Binutils, Coreutils,
    Diffutils, GCC, Gettext, Glibc, Grep, M4, Make, 和　Sed

    5.31.1. 安装 Bison

    为编译 Bison 做准备： 

    ./configure --prefix=/tools

    编译软件包： 

    make

    测试结果，执行：make
    check    .

    安装软件包： 

    make install

    本软件包的详细内容在  6.25.2,
    “Bison　的内容”    　一节中可以找到。

    --------------------------------------------------------------------------------------------------------------------------

    The Bison package contains a parser generator.

    Approximate build time: 0.6 SBU

    Required disk space: 10.6 MB

    Bison installation depends on: Bash, Binutils, Coreutils,
    Diffutils, GCC, Gettext, Glibc, Grep, M4, Make, and Sed

    5.31.1. Installation of Bison

    Prepare Bison for compilation: 

    ./configure --prefix=/tools

    Compile the package: 

    make

    To test the results, issue: make
    check    .

    Install the package: 

    make install

    Details on this package are located in Section 6.25.2,
    “Contents of Bison.”

5.32. Flex-2.5.31

  • Flex 软件包含有文本模式识别程序生成器。

    预计编译时间： 0.6 SBU

    所需硬盘空间： 10.6 MB

    Flex 安装依赖于： Bash, Binutils, Bison,
    Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, M4, Make　和
    Sed

    5.32.1. 安装 Flex

    Flex 有几个众所周知的 bug，可以用下列补丁来修复： 

    patch -Np1 -i ../flex-2.5.31-debian_fixes-2.patch

    GNU autotools 会检测到　Flex 源码被上面的那个补丁改动过，因而会自动更新用户手册。这个操作在许多系统上会失败，由于缺省的用户手册就不错，所以我们不更新它： 

    touch doc/flex.1

    为编译 Flex 做准备： 

    ./configure --prefix=/tools

    编译软件包： 

    make

    测试结果，执行：make
    check    .

    安装软件包： 

    make install

    本软件包的详细内容在　 6.29.2,
    “Flex　的内容”    　一节中可以找到。

    ---------------------------------------------------------------------------------------------------------------------------

    The Flex package contains a utility for generating programs that
    recognize patterns in text.

    Approximate build time: 0.6 SBU

    Required disk space: 10.6 MB

    Flex installation depends on: Bash, Binutils, Bison,
    Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, M4, Make, and
    Sed

    5.32.1. Installation of Flex

    Flex contains several known bugs. These can be fixed with the
    following patch: 

    patch -Np1 -i ../flex-2.5.31-debian_fixes-2.patch

    The GNU autotools will detect that the Flex source code has been
    modified by the previous patch and tries to update the manual page
    accordingly. This does not work on many systems, and the default
    page is fine, so make sure it does not get regenerated: 

    touch doc/flex.1

    Now prepare Flex for compilation: 

    ./configure --prefix=/tools

    Compile the package: 

    make

    To test the results, issue: make
    check    .

    Install the package: 

    make install

    Details on this package are located in Section 6.29.2,
    “Contents of Flex.”

5.33. Util-linux-2.12b

  • Util-linux 软件包含有多种工具，可用于处理文件系统、控制台、分区和消息等。

    预计编译时间： 0.2 SBU

    所需硬盘空间： 16 MB

    Util-linux 安装依赖于： Bash, Binutils,
    Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make, Ncurses,
    Sed, 和 Zlib

    5.33.1. 安装 Util-linux

    Util-linux 不使用　/tools 目录下新安装的头文件和库文件。通过下列命令，更改配置脚本，可以修正： 

    sed -i 's@/usr/include@/tools/include@g' configure

    为编译 Util-linux 做准备： 

    ./configure

    编译支持库： 

    make -C lib

    我们只需要几个工具，所以只编译它们： 

    make -C mount mount umount
make -C text-utils more

    本软件包不附带测试套件。

    把这些程序拷贝到临时的工具目录： 

    cp mount/{,u}mount text-utils/more /tools/bin

    本软件包的详细内容在  6.58.3,
    “Util-linux 的内容”     一节中可以找到。

    -------------------------------------------------------------------------------------------------------------------------------

    The Util-linux package contains miscellaneous utility programs.
    Among them are utilities for handling file systems, consoles,
    partitions, and messages.

    Approximate build time: 0.2 SBU

    Required disk space: 16 MB

    Util-linux installation depends on: Bash, Binutils,
    Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make, Ncurses,
    Sed, and Zlib

    5.33.1. Installation of Util-linux

    Util-linux does not use the freshly installed headers and libraries
    from the /tools directory. This is fixed
    by altering the configure script: 

    sed -i 's@/usr/include@/tools/include@g' configure

    Prepare Util-linux for compilation: 

    ./configure

    Compile some support routines: 

    make -C lib

    Since only a couple of the utilities contained in this package are
    needed, build only those: 

    make -C mount mount umount
make -C text-utils more

    This package does not come with a test suite.

    Copy these programs to the temporary tools directory: 

    cp mount/{,u}mount text-utils/more /tools/bin

    Details on this package are located in Section 6.58.3,
    “Contents of Util-linux.”

5.34. Perl-5.8.5

  • Perl 软件包包含实用抽象报告语言。

    预计编译时间： 0.8 SBU

    所需硬盘空间： 74 MB

    Perl 安装依赖于： Bash, Binutils, Coreutils,
    Diffutils, Gawk, GCC, Glibc, Grep, Make 和 Sed

    5.34.1. 安装 Perl

    首先应用以下补丁，修改 C 库的硬连接路径: 

    patch -Np1 -i ../perl-5.8.5-libc-1.patch

    为编译 Perl 做准备( 一定把命令中的“IO Fcntl POSIX”打准确--全是字母，没有数字)： 

    ./configure.gnu --prefix=/tools -Dstatic_ext='IO Fcntl POSIX'

    配置选项说明：

     

    -Dstatic_ext='IO
    Fcntl POSIX'

    本选项告诉 Perl 编译静态扩展的最小集合，用来在下一章里安装和测试 Coreutils 软件包。

     

     

    编译必需工具： 

    make perl utilities

    尽管 Perl 自带测试套件，这里不推荐运行它。由于只编译了一部份 Perl，运行 make test 会编译其余我们不需要的 Perl。如果想的话，可以在下一章里运行。

    复制这些工具和它们的库: 

    cp perl pod/pod2man /tools/bin
mkdir -p /tools/lib/perl5/5.8.5
cp -R lib/* /tools/lib/perl5/5.8.5

    更多关于软件包的资料在  6.33.2,
    “Perl 的内容”     一节里可以找到。

    --------------------------------------------------------------------------------------------------------------------------------

    The Perl package contains the Practical Extraction and Report
    Language.

    Approximate build time: 0.8 SBU

    Required disk space: 74 MB

    Perl installation depends on: Bash, Binutils, Coreutils,
    Diffutils, Gawk, GCC, Glibc, Grep, Make, and Sed

    5.34.1. Installation of Perl

    First adapt some hard-wired paths to the C library by applying the
    following patch: 

    patch -Np1 -i ../perl-5.8.5-libc-1.patch

    Prepare Perl for compilation (make sure to get the 'IO Fcntl POSIX'
    part of the command correct—they are all letters): 

    ./configure.gnu --prefix=/tools -Dstatic_ext='IO Fcntl POSIX'

    The meaning of the configure option:

     

    -Dstatic_ext='IO
    Fcntl POSIX'

    This tells Perl to build the minimum set of static extensions
    needed for installing and testing the Coreutils package in
    the next chapter.

     

     

    Compile only the required tools: 

    make perl utilities

    Although Perl comes with a test suite, it is not recommended to run
    it at this point. Only part of Perl was built and running make test now will cause the rest of Perl
    to be built as well, which is unnecessary at this point. The test
    suite can be run in the next chapter if desired.

    Copy these tools and their libraries: 

    cp perl pod/pod2man /tools/bin
mkdir -p /tools/lib/perl5/5.8.5
cp -R lib/* /tools/lib/perl5/5.8.5

    Details on this package are located in Section 6.33.2,
    “Contents of Perl.”

5.35. 安装Udev-030

  • Udev 软件用于动态地创建设备节点.

    估计创建时间: 0.2 SBU

    需要硬盘空间: 5.2 MB

    Udev 安装依赖于: Coreutils 和 Make

    5.35.1. 安装 Udev

    udevstart 程序固定将路径指向udev 程序自身
    ，因此会引起udev 安装在一个非标准的位置。
    下面的命令解决了这个问题： 

    sed -i 's@/sbin/udev@/tools/sbin/udev@g' udevstart.c

    同样，要确保 udev 知道正确查找配置文件的位置： 

    sed -i 's@/etc@/tools/etc@g' etc/udev/udev.conf.in

    现在可以开始编译 Udev: 

    make prefix=/tools etcdir=/tools/etc

    此软件包没有测试套件.

    安装软件包: 

    make DESTDIR=/tools udevdir=/dev install

    Udev 的默认配置文件并不理想，因此需要安装 LFS 指定的配置文件： 

    cp ../udev-config-2.permissions /
    /tools/etc/udev/permissions.d/00-lfs.permissions
cp ../udev-config-1.rules /tools/etc/udev/rules.d/00-lfs.rules

    软件包详述见 Section 6.57.2,
    “Contents of Udev.”
    --------------------------------------------------------------------------------------------------------------------

    The Udev package contains programs for dynamic creation of device
    nodes.

    Approximate build time: 0.2 SBU

    Required disk space: 5.2 MB

    Udev installation depends on: Coreutils and Make

    5.35.1. Installation of Udev

    The udevstart program hardcodes
    the path to the udev program in
    itself, which would cause issues since udev was installed in a non-standard location.
    Fix this by running the following: 

    sed -i 's@/sbin/udev@/tools/sbin/udev@g' udevstart.c

    Also, ensure that udev knows
    the correct location to look for its configuration files: 

    sed -i 's@/etc@/tools/etc@g' etc/udev/udev.conf.in

    Now compile Udev: 

    make prefix=/tools etcdir=/tools/etc

    This package does not come with a test suite.

    Install the package: 

    make DESTDIR=/tools udevdir=/dev install

    Udev's configuration is far from ideal by default, so install
    LFS-specific configuration files here: 

    cp ../udev-config-2.permissions /
    /tools/etc/udev/permissions.d/00-lfs.permissions
cp ../udev-config-1.rules /tools/etc/udev/rules.d/00-lfs.rules

    Details on this package are located in Section 6.57.2,
    “Contents of Udev.”

5.36. Stripping

  • 本小节的步骤是可选的，但是如果LFS分区实在太小，了解哪些没用的东西可以删
    除是有好处的。已经装好的可知性文件和库文件含有大约130MB没用的调试符号。
    可以用下面的命令删除这些符号： 

    strip --strip-debug /tools/lib/*
strip --strip-unneeded /tools/{,s}bin/*

    以上命令会跳过大约20个文件，报告说这些文件的格式是不认识的。其中大多数是
    脚本而不是二进制文件。

    小心不要在库文件上使用--strip-unneeded。 否则其静态版本会坏掉，于是工具链软件包
    就需要重新构建一遍。

    要想多释放30MB出来，可以把文档删掉： 

    rm -rf /tools/{doc,info,man}

    现在LFS文件系统上将需要至少850MB的空间去编译和安装下一章的Glibc。
    如果编译和 安装Glibc没问题了，那么剩下的软件包就都没问题了。

    >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

    The steps in this section are optional, but if the LFS partition is
    rather small, it is beneficial to learn that unnecessary items can be
    removed. The executables and libraries built so far contain about 130
    MB of unneeded debugging symbols. Remove those symbols with: 

    strip --strip-debug /tools/lib/*
strip --strip-unneeded /tools/{,s}bin/*

    The last of the above commands will skip some twenty files, reporting
    that it does not recognize their file format. Most of these are
    scripts instead of binaries.

    Take care not to use --strip-unneeded on the libraries. The
    static ones would be destroyed and the toolchain packages would need
    to be built all over again.

    To save another 30 MB, remove the documentation: 

    rm -rf /tools/{doc,info,man}

    There will now be at least 850 MB of free space on the LFS file
    system that can be used to build and install Glibc in the next phase.
    If you can build and install Glibc, you can build and install the
    rest too.

babyfans
关注
3-1：常见任务和主要工具之软件包管理
快乐江湖的博客
03-16 342
文章目录前言一：软件包系统二：软件包系统的工作方式（1）软件包文件 前言 Linux发行版本众多这一点我们是知道的，所以选择哪一种发行版本就显得有点焦灼了。但是大部分人选择发行版本是只有一个标准——这个版本图形界面是不是很漂亮，界面是不是很酷等等。当然这只是小白，或者只是为了使用Linux在朋友面前满足一下虚荣感的人所干的事情。 要看一个Linux发行版本好不好，其中有一个非常重要的指标就是——软件包系统。软件包系统包括软件包和软件包管理器，你可以将其理解为app和app store的关系。因为在早期在Li
Linux应用编程---库制作
weixin_41884251的博客
12-16 1446
动态库的制作 想要把当前的目录下文件做成动态库 修改makefile CC := gcc TARGET := libXXXX.so SRC := $(wildcard ./*.c) OBJS := $(patsubst %.c, %.o, $(SRC)) LIBS+= -lpthread -lm CFLAGS = -O2 -Wall -g -fPIC all: $(OBJS) $(CC) -o $(TARGET) $(OBJS) $(LIBS) -shared %.o:%.c $(CC) $(CFLA
【问题】relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `_ZTVSt9basic_iosIcSt11char_traitsIcEE
勤又氪猿的博客
04-12 1606
relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `_ZTVSt9basic_iosIcSt11char_traitsIcEE@@GLIBCXX_3.4' which may bind externally can not be used when making a shared object; recompile with -fPIC 错误
C++编译问题，解决arm下链接静态库，引起的relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol错误...
SurpassLi的专栏
07-02 531
显示的完整错误如下： relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `ZN2c43yml9free_implEPvmS1' which may bind externally can not be used when making a shared object; recompile with -fPIC 根据提示，在链接.a静态库时，...
dangerous relocation: unsupported relocation 解决方案
Nyiragongo的博客
01-12 6884
在编译过程中出先如下 error log usr/bin/ld: CMakeFiles/Atlas.dir///host/des_engine.cpp.o: relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `_ZTV9DesEngine’ which may bind externally can not be used when making a shared object; recompile with -fPIC dangerous reloc
ARM环境手动编译StarRocks-2.0
qq_35174440的博客
02-19 1706
ARM环境手动编译StarRocks
Openssl aarch64 静态库使用遇到libcrypto.a(xxxx-armv8.o)……问题解决方案记录
太白的博客
04-13 4268
使用方式 在CPU构架为arrch64(arm64)的系统下静态链接libcrypto.a 与libssl.a 错误 ……Linux/aarch64/libcrypto.a(sha1-armv8.o): relocation R_AARCH64_PREL64 against symbol `OPENSSL_armcap_P' which may bind externally can not be used when making a shared object; recompile with -fPIC
"多尺度分析R软件包EPT：集成补丁变换的实现和可视化工具
≥软件X 14（2021）100704原始软件出版物EPT：一个用于整体分片变换的R软件包Donghoh Kima，Chong，Hee-Seok Ohb，Guebin Choica大韩民国首尔世宗大学数学和统计系b大韩民国首尔国立大学统计系c大韩民国全北国立大学...
Citros:Citros的软件包列表，更新和其他内容
03-21
在 Citros 的软件生态系统中，开发者和用户还可以利用 APT (Advanced Package Tool) 或 YUM (Yellowdog Updater, Modified) 这样的包管理系统，它们不仅管理本地安装的软件，还连接到官方或第三方的软件仓库，从那里...
TSMaster 软件包下载
06-26
这个版本号 V2021.3.10.437 暗示这是 2021 年 3 月 10 日发布的第 437 个修订版，通常意味着软件的稳定性和功能都得到了持续的改进和增强。 安装步骤通常包括： 1. 下载并解压“TSMaster_Setup_V2021.3.10.437.exe...
麒麟服务器操作系统漏洞补丁包怎么快速下载
最新发布
太极淘的博客
07-04 479
2、在对应版本的服务器系统中修改好repo文件，如果在x86系统中下载aarch64的补丁包，可以将repo中的$basearch替换为aarch64.[root@localhost sp1bug]# vim list.txt #将第一步的所有https的下载地址放到该文件中。[root@localhost ~]# tr ‘、’ ’ ’ < package.txt #将文本文件中的顿号都换成空格。注意：系统内如果该依赖包已安装，那么运行命令时将不会下载已安装的依赖包。第一种方案：【建议方案】
gcc 编译连接
lbaihao的专栏
12-04 4777
http://sourceware.org/binutils/docs-2.23.1/ld/Options.html#Options 本人的错误是gcc的时候出现了.note.gnu.build-id 这个段号 这个可以通过 编译的时候加上 -Wl,--build-id=none 通过 objdump –h (ELF文件)来查看文件的段号 详细见http://sourcewar
gcc492 compile `.rodata‘ can not be used when making a PIE object； recompile with -fPIE
qq_38963393的博客
08-10 621
linux
cannot install both readline-8.0-1.h3.eulerosv2r9.x86_64 and readline-7.0-13.oe1.x86_64
weixin_59842401的博客
11-15 652
解决这个问题的方法是安装正确版本的readline库，或者卸载已安装的readline库并重新安装正确版本的readline库。yum remove readline Error: Problem: 这个操作可能会导致删除以下受保护的软件包： dnf (try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)
关于编译安装提示No package ** found时可能需配置pkg-config
热门推荐
拭血的专栏
05-14 2万+
在编译安装时，可能出现： No package '**' found Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix. Alternatively, you may set the environment variables OPENSSL_CFLAGS and OPENSSL_LIBS to avoid the need to
v10 server 安装EPEL、PowerTools 存储库【1】
CoolGirl
02-01 2626
下一步是安装 EPEL。EPEL 是 Extra Packages for Enterprise Linux 的首字母缩写词，是一个存储库，提供一组来自 Fedora 默认情况下不包含在 Red Hat 和 Red Hat 发行版（如 Rocky 和 AlmaLinux）上的项目。第三步：解决第二步的报错，为了避免删除与该软件包相关的依赖包，换一种方式只删除该软件包。该命令提供了复杂的详细信息，例如 EPEL 的名称、版本发布和架构。安装后，转到下一步并启用 EPEL 存储库。此时，该软件包已被删除。
链接静态库时报can not be used when making a PIE object； recompile with -fPIE
yuanlulu的博客
07-04 2766
链接了一个SDK的静态库，报了大量的错误都是 后在编译选项中加了-no-pie解决。
Linux From Scratch：软件包与补丁下载及构建过程
在第三章“软件包与补丁”中，主要介绍了构建基础Linux系统所需的软件包及其处理方法。 1. **简介**：本章列出了构建LFS系统所需的所有软件包和补丁，并强调了使用特定版本的原因。这些版本经过验证能够正常工作，...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值