5.11. GCC-4.0.3 - 第二遍

GCC 软件包包含 GNU 编译器集合,其中有C和C++编译器。

预计编译时间: 4.2 SBU
所需磁盘空间: 443 MB

5.11.1. 重新安装 GCC

测试 GCC 和 Binutils 所需的工具(Tcl, Expect, DejaGNU)已经安装好。现在 GCC 和 Binutils 将被重新编译,连接到新的 Glibc 并作适当测试(如果运行这章中的测试的话)。注意,这些测试套件受伪终端(PTY)的影响很大,这些伪终端通常是由宿主系统通过 devpts 文件系统实现的。你可以用下面的方法,来测试宿主系统中PTY是否设置正常:

expect -c "spawn ls"

如果你得到下面的回答:

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

说明主系统的 PTY 没设置好。这种情况下,运行 GCC 和 Binutils 的测试套件就没什么意义了。你需要先解决主系统中的 PTY 设置问题。具体请参见 LFS 的 FAQ :http://www.linuxfromscratch.org/lfs/faq.html#no-ptys

在之前的节 5.7, "调整工具链"中我们提到过在 GCC 编译过程中会运行 fixincludes 脚本来扫描系统头文件目录,并找出需要修正的头文件,然后把修正后的头文件放到 GCC 专属头文件目录里。因为现在 GCC 和 Glibc 已经安装完毕,而且它们的头文件已知无需修正,所以这里并不需要 fixincludes 脚本。另外,由于 GCC 专属头文件目录会被优先搜索,结果就是 GCC 使用的头文件是宿主系统的头文件,而不是新安装的那个,从而导致编译环境被"污染"。因此必须通过下面的命令来禁止 fixincludes 脚本运行:

cp -v gcc/Makefile.in{,.orig} &&
sed '[email protected]\./fixinc\[email protected] [email protected]' gcc/Makefile.in.orig > gcc/Makefile.in

节 5.4, "GCC-4.0.3 - 第一遍"中进行的 bootstrap 编译使用了 -fomit-frame-pointer 选项,而非 bootstrap 编译则默认忽略了该选项,所以需要使用下面的 sed 命令来确保在非 bootstrap 编译时也同样使用 -fomit-frame-pointer 选项,以保持一致性:

cp -v gcc/Makefile.in{,.tmp} &&
sed 's/^XCFLAGS =$/& -fomit-frame-pointer/' gcc/Makefile.in.tmp \
  > gcc/Makefile.in

使用下面的补丁修改 GCC 的缺省动态连接器(通常是 ld-linux.so.2)的位置:

patch -Np1 -i ../gcc-4.0.3-specs-1.patch

上述补丁还把 /usr/include 从 GCC 的头文件搜索路径里删掉。现在预先打补丁而不是在安装 GCC 之后调整 specs 文件可以保证新的动态连接器在编译 GCC 的时候就用上。也就是说,随后的所有临时程序都会连接到新的 Glibc 上。

[Important]

重要

上述补丁非常重要,为了成功编译,千万别忘了使用它们。

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

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

在开始编译前,别忘了 unset 任何优化相关的环境变量。[是不是应当省略这句?]

为编译 GCC 做准备:

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

新配置选项的含义:

--enable-clocale=gnu

本参数确保 C++ 库在任何情况下都使用正确的 locale 模块。如果配置脚本查找到 de_DE 这个 locale ,它就会使用正确的 gnu locale 模块。然而,如果没有安装 de_DE ,就有可能创建出应用程序二进制接口(ABI)不兼容的 C++ 库文件,这是因为选择了错误的通用(generic) locale 模块。

--enable-threads=posix

使 C++ 异常能处理多线程代码。

--enable-__cxa_atexit

__cxa_atexit 代替 atexit 来登记 C++ 对象的本地静态和全局析构函数,这是为了完全符合标准对析构函数的处理规定。它还会影响到 C++ ABI ,因此生成的 C++ 共享库在其他的 Linux 发行版上也能使用。

--enable-languages=c,c++

本参数编译 C 和 C++ 语言的编译器。

--disable-libstdcxx-pch

不为 libstdc++ 编译预编译头(PCH),它占用了很大空间,但是我们用不到它。

对于如何安装 Binutils 和 GCC 可以参考一下《Binutils与GCC配置选项简介》

编译软件包:

make

现在没必要用 bootstrap 作为 make 的目标,因为这里 GCC 是用相同版本的 GCC 来编译的,其实连源码都一模一样,就是在第一遍的时候安装的那个。

现在编译完成了,早先我们谈到过,本章中的临时工具的测试程序并不是必须运行的,如果您要运行 GCC 的测试程序,请输入下面的命令:

make -k check

-k 参数是让测试套件即使遇到错误,也继续运行,直到完成。GCC 的测试套件非常全面,所以基本上总是会出一些错的。

对于测试错误的重要说明位于节 6.12, "GCC-4.0.3."

安装软件包:

make install
[Caution]

小心

现在,需要停下来再一次确认新工具链的基本功能(编译和连接)是否按预期工作,运行下面的命令做一个简单的合理性检查:

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

如果一切正常,应该不会出错,而且最后一个命令的结果应当是:

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

注意,/tools/lib 应该是动态连接器的前缀。

如果输出不是像上面那样或者根本没有输出,那么就有大问题了。返回并检查前面的操作,找出问题,并改正过来。在改正之前,不要继续后面的部份,因为这样做没有意义。首先,再次上述合理性检查,用 gcc 代替 cc ,如果工作正常,那么是因为 /tools/bin/cc 这个符号链接丢失了。回头看看节 5.4, "GCC-4.0.3 - 第一遍," 并建立符号链接。接下来,确保 PATH 正确。检查时,运行 echo $PATH 并检查 /tools/bin 是否在列表的最前面。如果 PATH 错误,可能是因为你没有以 lfs 用户登录,或者在 节 4.4, "设置工作环境."部分出错了。另外一个原因可能是上面修正 specs 文件时出错,如果这样,重新修改 specs 文件,复制粘贴时小心。

在确定一切正常后,删除测试文件:

rm -v dummy.c a.out

关于这个软件包的详细资料位于节 6.12.2, GCC 的内容