关于这个软件包的详细资料位于节 6.12.2, GCC 的内容
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 's@\./fixinc\.sh@-c true@' 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]](../images/important.png)
重要
上述补丁非常重要，为了成功编译，千万别忘了使用它们。
再次为编译创建一个单独目录：
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
![[Caution]](../images/caution.png)
小心
现在，需要停下来再一次确认新工具链的基本功能(编译和连接)是否按预期工作，运行下面的命令做一个简单的合理性检查：
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