1.8.11 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 。
在之前的节 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 上。
重要
上述补丁非常重要,为了成功编译,千万别忘了使用它们。
再次为编译创建一个单独目录:
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),它占用了很大空间,但是我们用不到它。
编译软件包:
make
现在没必要用 bootstrap
作为 make 的目标,因为这里 GCC 是用相同版本的 GCC 来编译的,其实连源码都一模一样,就是在第一遍的时候安装的那个。
现在编译完成了,早先我们谈到过,本章中的临时工具的测试程序并不是必须运行的,如果您要运行 GCC 的测试程序,请输入下面的命令:
make -k check
-k
参数是让测试套件即使遇到错误,也继续运行,直到完成。GCC 的测试套件非常全面,所以基本上总是会出一些错的。
对于测试错误的重要说明位于节 6.12, "GCC-4.0.3."。
安装软件包:
make install
小心
现在,需要停下来再一次确认新工具链的基本功能(编译和连接)是否按预期工作,运行下面的命令做一个简单的合理性检查:
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 的内容