8.28.1. 安装 GCC
再次修复 GCC 13.2.0 中导致 Binutils-2.42 链接生成的可执行文件可能包含非法指令的问题:
sed -e '/ASM_OUTPUT_ALIGN_WITH_NOP/,+1d' \
-i gcc/config/loongarch/loongarch.h
设置存放 64 位库的默认目录为 “lib”:
sed -e 's/lib64/lib/' \
-i.orig gcc/config/loongarch/{t-linux,linux.h}
GCC 文档建议在一个新建的目录中构建 GCC:
mkdir -v build
cd build
准备编译 GCC:
../configure --prefix=/usr \
LD=ld \
--enable-languages=c,c++ \
--enable-default-pie \
--enable-default-ssp \
--disable-multilib \
--disable-bootstrap \
--disable-fixincludes \
--with-system-zlib
GCC 支持七种程序设计语言,但其中多数语言需要尚未安装的依赖项。阅读
BLFS 手册,以了解如何构建 GCC 支持的所有语言。
新的配置选项的含义:
-
LD=ld
-
该选项使得配置脚本使用之前在本章中构建的 Binutils 提供的 ld 程序,而不是交叉编译构建的版本。
-
--disable-fixincludes
-
默认情况下,在安装 GCC 时,一些系统头文件会被“修复”以供 GCC 使用。这对于现代的 Linux
系统来说是不必要的,而且如果一个软件包在安装 GCC 后被重新安装,还可能造成损害。这个开关阻止 GCC
尝试“修复”头文件。
-
--with-system-zlib
-
该选项使得 GCC 链接到系统安装的 Zlib 库,而不是它自带的 Zlib 副本。
注意
PIE (位置无关可执行文件) 是能加载到内存中任意位置的二进制程序。在不使用 PIE 时,称为 ASLR (地址空间布局随机化)
的安全特性能被用于共享库,但不能被用于可执行程序本身。启用 PIE 使得 ASLR
在作用于共享库的同时,同样作用于可执行程序,以预防一些基于可执行程序中关键代码或数据的固定地址的攻击。
SSP (栈溢出防护)
是保证程序的调用栈不被破坏的技术。在调用栈被破坏时可能导致安全问题,例如子程序的返回地址可能被修改,进而执行一些危险代码
(这些危险代码可能已经存在于程序或共享库中,或被攻击者用某种方式注入)。
编译该软件包:
make
重要
在本节中,GCC 的测试套件十分重要,但需要消耗较长的时间。我们建议首次编译 LFS 的读者运行测试套件。通过在以下命令中添加
-jx 参数,可以显著降低测试需要的时间,其中 x 表示系统 CPU 核心数。
已知 GCC 测试套件中的一组测试可能耗尽默认栈空间,因此运行测试前要增加栈空间:
ulimit -s 32768
以非特权用户身份测试编译结果,但出错时继续执行其他测试:
chown -R tester .
su tester -c "PATH=$PATH make -k check"
输入以下命令提取测试结果的摘要:
../contrib/test_summary
如果只想看摘要,将输出用管道送至 grep -A7
Summ
。
可以将结果与 https://www.linuxfromscratch.org/lfs/build-logs/loongarch-12.1/
和 https://gcc.gnu.org/ml/gcc-testresults/
的结果进行比较。
已知十二项 gcc 测试 (共有超过 150,000 项):analyzer
目录中的七项测试,一项名为 gcc.dg/uninit-pred-9_b.c
的测试,一项名为 pr108357.c
的测试,一项名为 ssa-dom-cse-2.c
的测试,以及两项 “stack-check-cfa-*.c”
测试会失败。在 g++ 测试中,已知 23 项测试 (共计有约 250,000 项测试):14 项 “AddressSanitizer*” 测试,7
项 interception-malloc-test-1.C
测试,一项
pr90883.C
测试,以及一项 pr64076
测试会失败。
少量意外的失败有时无法避免,GCC 开发者一般知道这类问题,但尚未解决它们。我们可以继续安全地构建系统,除非测试结果和以上 URL
的结果截然不同。
安装该软件包:
make install
GCC 构建目录目前属于用户 tester
,导致安装的头文件目录
(及其内容) 具有不正确的所有权。将所有者修改为 root
用户和组:
chown -v -R root:root \
/usr/lib/gcc/$(gcc -dumpmachine)/13.2.0/include{,-fixed}
创建一个 FHS
因 “历史原因” 要求的符号链接。
ln -svr /usr/bin/cpp /usr/lib
许多软件包使用 cc 这一名称调用 C
编译器。在第二遍的 GCC 中我们已经将 cc 创建为符号链接,这里将其手册页也创建为符号链接:
ln -sv gcc.1 /usr/share/man/man1/cc.1
创建一个兼容性符号链接,以支持在构建程序时使用链接时优化 (LTO):
ln -sfv ../../libexec/gcc/$(gcc -dumpmachine)/13.2.0/liblto_plugin.so \
/usr/lib/bfd-plugins/
现在最终的工具链已经就位,重要的是再次确认编译和链接像我们期望的一样正常工作。为此,进行下列完整性检查:
echo 'int main(){}' > dummy.c
cc dummy.c -v -Wl,--verbose &> dummy.log
readelf -l a.out | grep ': /lib'
上述命令不应该出现错误,最后一行命令输出的结果应该 (不同平台的动态链接器名称可能不同) 是:
[Requesting program interpreter: /lib64/ld-linux-loongarch-lp64d.so.1]
下面确认我们在使用正确的启动文件:
grep -E -o '/usr/lib.*/S?crt[1in].*succeeded' dummy.log
以上命令应该输出:
/usr/lib/gcc/loongarch64-unknown-linux-gnu/13.2.0/../../../../lib/Scrt1.o succeeded
/usr/lib/gcc/loongarch64-unknown-linux-gnu/13.2.0/../../../../lib/crti.o succeeded
/usr/lib/gcc/loongarch64-unknown-linux-gnu/13.2.0/../../../../lib/crtn.o succeeded
以上结果可能随您的机器体系结构不同而略微不同。差异在于 /usr/lib/gcc
之后的目录名。我们关注的重点是,gcc 应该找到所有三个 crt*.o
文件,它们应该位于 /usr/lib
目录中。
确认编译器能正确查找头文件:
grep -B4 '^ /usr/include' dummy.log
该命令应当输出:
#include <...> search starts here:
/usr/lib/gcc/x86_64-pc-linux-gnu/13.2.0/include
/usr/local/include
/usr/lib/gcc/x86_64-pc-linux-gnu/13.2.0/include-fixed
/usr/include
同样要注意,以您的目标三元组命名的目录由于您体系结构的不同,可能和以上不同。
下一步确认新的链接器使用了正确的搜索路径:
grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g'
那些包含 '-linux-gnu' 的路径应该忽略,除此之外,以上命令应该输出:
SEARCH_DIR("/usr/x86_64-pc-linux-gnu/lib64")
SEARCH_DIR("/usr/local/lib64")
SEARCH_DIR("/lib64")
SEARCH_DIR("/usr/lib64")
SEARCH_DIR("/usr/x86_64-pc-linux-gnu/lib")
SEARCH_DIR("/usr/local/lib")
SEARCH_DIR("/lib")
SEARCH_DIR("/usr/lib");
之后确认我们使用了正确的 libc:
grep "/lib.*/libc.so.6 " dummy.log
以上命令应该输出:
attempt to open /usr/lib/libc.so.6 succeeded
确认 GCC 使用了正确的动态链接器:
grep found dummy.log
以上命令应该输出 (不同平台的动态链接器名称可能不同):
found ld-linux-loongarch-lp64d.so.1 at /usr/lib/ld-linux-loongarch-lp64d.so.1
如果输出和以上描述不符,或者根本没有输出,那么必然有什么地方出了严重错误。检查并重新跟踪以上步骤,找到问题的原因,并修复它。在继续构建前必须解决这里发现的所有问题。
在确认一切工作良好后,删除测试文件:
rm -v dummy.c a.out dummy.log
最后移动一个位置不正确的文件:
mkdir -pv /usr/share/gdb/auto-load/usr/lib
mv -v /usr/lib/*gdb.py /usr/share/gdb/auto-load/usr/lib