该软件包的详细信息可以在第 8.5.3 节 “Glibc 的内容”中找到。
Glibc 软件包包含主要的 C 语言库。它提供用于分配内存、检索目录、打开和关闭文件、读写文件、字符串处理、模式匹配、算术等用途的基本子程序。
首先,创建一个 LSB 兼容性符号链接。另外,对于 x86_64,创建一个动态链接器正常工作所必须的符号链接:
case $(uname -m) in i?86) ln -sfv ld-linux.so.2 $LFS/lib/ld-lsb.so.3 ;; x86_64) ln -sfv ../lib/ld-linux-x86-64.so.2 $LFS/lib64 ln -sfv ../lib/ld-linux-x86-64.so.2 $LFS/lib64/ld-lsb-x86-64.so.3 ;; esac
以上命令是正确的。ln
命令的语法有一些变式,因此在报告你认为的错误之前,请先阅读 info
coreutils ln 和 ln(1)
。
一些 Glibc 程序使用与 FHS 不兼容的 /var/db
目录存放它们的运行时数据。下面应用一个补丁,使得这些程序在 FHS 兼容的位置存放运行时数据:
patch -Np1 -i ../glibc-2.36-fhs-1.patch
Glibc 文档推荐在一个专用目录中构建 Glibc:
mkdir -v build cd build
确保将 ldconfig 和
sln 工具安装到
/usr/sbin
目录中:
echo "rootsbindir=/usr/sbin" > configparms
下面,准备编译 Glibc:
../configure \ --prefix=/usr \ --host=$LFS_TGT \ --build=$(../scripts/config.guess) \ --enable-kernel=3.2 \ --with-headers=$LFS/usr/include \ libc_cv_slibdir=/usr/lib
配置选项的含义:
--host=$LFS_TGT,
--build=$(../scripts/config.guess)
在它们的共同作用下,Glibc 的构建系统将自身配置为使用 $LFS/tools
中的交叉链接器和交叉编译器,进行交叉编译。
--enable-kernel=3.2
该选项告诉 Glibc 编译出支持 3.2 版或者更新的 Linux 内核,这样就不会使用那些为更老内核准备的替代方案。
--with-headers=$LFS/usr/include
该选项告诉 Glibc 在编译过程中,使用 $LFS/usr/include 目录中的头文件,这样它就知道内核拥有哪些特性,并据此对自身进行优化。
libc_cv_slibdir=/usr/lib
在 64 位机器上,这保证将库安装到 /usr/lib,而不是默认的 /lib64。
在当前阶段,可能出现下列警告:
configure: WARNING: *** These auxiliary programs are missing or *** incompatible versions: msgfmt *** some features will be disabled. *** Check the INSTALL file for required versions.
msgfmt 程序的缺失或不兼容一般是无害的。msgfmt 程序是 Gettext 软件包的一部分,宿主发行版应该提供它。
有报告称该软件包在并行构建时可能失败,如果发生了这种情况,加上 "-j1" 选项重新执行 make 命令。
编译该软件包:
make
安装该软件包:
如果 LFS
没有正确设定,而且您不顾本书的建议,以
root
用户的身份进行构建,下面的命令会将新构建的 glibc
安装到您的宿主系统中,这很可能导致宿主系统完全无法使用。因此,请再次检查该环境变量是否已经为 lfs
用户设定好。
make DESTDIR=$LFS install
make install 选项的含义:
DESTDIR=$LFS
多数软件包使用 DESTDIR
变量指定软件包应该安装的位置。如果不设定它,默认值为根 (/
)
目录。这里我们指定将软件包安装到 $LFS
,它在第 7.4 节 “进入 Chroot
环境”之后将成为根目录。
改正 ldd 脚本中硬编码的可执行文件加载器路径:
sed '/RTLDLIST=/s@/usr@@g' -i $LFS/usr/bin/ldd
现在我们不可避免地要停下确认新工具链的各基本功能 (编译和链接) 能如我们所预期的那样工作。执行以下命令进行完整性检查:
echo 'int main(){}' | gcc -xc - readelf -l a.out | grep ld-linux
如果一切正常,那么应该没有错误消息,而且最后一行命令应该输出下列格式的内容:
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
注意,对于 32 位机器,解释器的名字将会是 /lib/ld-linux.so.2
。
如果输出不像上面描述的那样,或者根本没有输出,就说明出了问题。检查并重新跟踪各个步骤,找到出问题的地方并修正它。在继续构建之前,必须解决这个问题。
检验步骤顺利完成后,清理测试文件:
rm -v a.out
在下一章中,构建各软件包的过程可以作为对工具链是否正常构建的额外检查。如果 一些软件包,特别是第二遍的 Binutils 或者 GCC 不能构建,说明在之前安装 Binutils,GCC,或者 Glibc 时出了问题。
现在我们的交叉工具链已经构建完成,可以完成 limits.h 头文件的安装。为此,运行 GCC 开发者提供的一个工具:
$LFS/tools/libexec/gcc/$LFS_TGT/12.2.0/install-tools/mkheaders
该软件包的详细信息可以在第 8.5.3 节 “Glibc 的内容”中找到。