# 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_](http://www.linuxfromscratch.org/lfs/faq.html#no-ptys) 。 在之前的[节 5.7, "调整工具链"](adjusting.html "5.7\. 调整工具链")中我们提到过在 GCC 编译过程中会运行 `fixincludes` 脚本来扫描系统头文件目录，并找出需要修正的头文件，然后把修正后的头文件放到 GCC 专属头文件目录里。因为现在 GCC 和 Glibc 已经安装完毕，而且它们的头文件已知无需修正，所以这里并不需要 `fixincludes` 脚本。另外，由于 GCC 专属头文件目录会被优先搜索，结果就是 GCC 使用的头文件是宿主系统的头文件，而不是新安装的那个，从而导致编译环境被"污染"。因此必须通过下面的命令来禁止 `fixincludes` 脚本运行： ``` cp -v gcc/Makefile.in{,.orig} && sed 's@\./fixinc\.sh@-c true@' gcc/Makefile.in.orig > gcc/Makefile.in ``` 在[节 5.4, "GCC-4.0.3 - 第一遍"](gcc-pass1.html "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."](../chapter06/gcc.html "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 - 第一遍,"](gcc-pass1.html "5.4\. GCC-4.0.3 - 第一遍") 并建立符号链接。接下来，确保 `PATH` 正确。检查时，运行 `echo $PATH` 并检查 `/tools/bin` 是否在列表的最前面。如果 `PATH` 错误，可能是因为你没有以 `lfs` 用户登录，或者在 [节 4.4, "设置工作环境."](../chapter04/settingenvironment.html "4.4\. 设置工作环境")部分出错了。另外一个原因可能是上面修正 specs 文件时出错，如果这样，重新修改 specs 文件，复制粘贴时小心。 在确定一切正常后，删除测试文件： ``` rm -v dummy.c a.out ``` 关于这个软件包的详细资料位于[节 6.12.2, GCC 的内容](../chapter06/gcc.html#contents-gcc "6.12.2\. GCC 的内容")