打印

LFS chroot 安装 gcc 后编译测试 ld 路径和手册不一致

LFS chroot 安装 gcc 后编译测试 ld 路径和手册不一致

各位兄台,chroot 之后,安装手册编译安装 gcc 后,编译 dummy.c 测试 ld 路径和手册的不一样:

http://www.linuxfromscratch.org/lfs/view/7.3/chapter06/gcc.html

手册中输出是:
复制内容到剪贴板
代码:
echo 'main(){}' > dummy.c
cc dummy.c -v -Wl,--verbose &> dummy.log
readelf -l a.out | grep ': /lib'
[Requesting program interpreter: /lib/ld-linux.so.2]
我执行 readelf -l a.out | grep ': /lib' 的输出是空,过滤 lib 关键字得到的位置:
复制内容到剪贴板
代码:
# readelf -l a.out | grep 'lib'
[Requesting program interpreter: /tools/lib64/ld-linux-x86-64.so.2]
后面还有一个 连接器 路径测试,这个输出是对的 :
复制内容到剪贴板
代码:
# grep found dummy.log
found ld-linux-x86-64.so.2 at /lib64/ld-linux-x86-64.so.2
其他所有 gcc 测试输出都合手册的一样的。

各位兄台,这两个测试连接器的路径的测试有什么不同?

不知道编译测试的不一致的问题出在哪里?

是否影响后面的继续?

TOP

这次编译出来的程序,确实应该不再是连接到 /tools 才对。

不过也有这么一个问题,当前系统的运行,应该还是基于 /tools 才对。
readelf 输出的结果是当前运行时检索到的 ld.so ,还是编译时 ld.so 呢?
这个好像应该是当前系统运行的链接库地址吧?

Requesting program interpreter 这句应该是说经过系统运行态调用得到的地址吧?

TOP

在之前调节工具链的那节。也有个类似的测试,我记得当时测试是何手册一样的。

重新阅读调整工具链那节:

    http://www.linuxfromscratch.org/lfs/view/7.3/chapter06/adjusting.html

编译安装好 gcc 后,找不到在 调整工具链那节生成的 specs 文件:
复制内容到剪贴板
代码:
# `dirname $(gcc --print-libgcc-file-name)`/specs
    bash: /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/specs: No such file or directory
我重新根据 [调整工具链] 这节,重新生成 gcc 的 specs 文件
复制内容到剪贴板
代码:
gcc -dumpspecs | sed -e 's@/tools@@g' \
        -e '/\*startfile_prefix_spec:/{n;s@.*@/usr/lib/ @}' \
        -e '/\*cpp:/{n;s@$@ -isystem /usr/include@}' > \
        `dirname $(gcc --print-libgcc-file-name)`/specs
重新编译测试之后,ld 的路径是对的:
复制内容到剪贴板
代码:
root:/sources/gcc-build# cc dummy.c -v -Wl,--verbose &> dummy.log
    root:/sources/gcc-build# readelf -l a.out | grep ': /lib'
          [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
1. 不知道为什么 gcc 的 specs 文件会弄丢了
2. 我确认在 adjusting 工具链那节,是存在的,并且测试也是 OK 的
3. 如果重新创建 gcc 的 specs 文件,对之前和之后是否要重新编译一遍?

我不知道这个错误的后果是什么?是 glibc / gcc 还是其他的程序需要重新再编译安装一遍?

TOP

这节调整工具链的目的很明显
1、把 ld-new 替换之前的ld 命令,ld-new 默认是去tools中查找可用lib(之前的binutils第二遍编译可以看到)
2、第二调整gcc 的spec,让gcc默认不去tools中查找lib,这样我们在使用gcc做后面编译的时候就会产生如下一个效果:
gcc本身是调用 ar ld 等命令去完成编译的,所以 gcc中配置不去tools中查找lib,但是如果/usr/lib 中没有程序编译连接的动态库的时候,ld还是会去tools中去寻找lib,这样此消彼长最终脱离了 /tools 工具链。

你这样调节后应该是没有问题,因为现在只是调整工具链,并没有进行后面的编译。输出结果正确才可以进行下面的编译。

加油,就快要脱离系统了

TOP

回复 4# zy_sunshine 的帖子

----


问题是出现在调整工具链之后,编译安装 LFS 的 gcc 后(6.17. GCC-4.7.2 )的 test :

发现 ld 用的还是工具链的中的路径

但是在前面工具链调整那节(6.10. Adjusting the Toolchain )是调节过,而且根据手册测试都是正常的

现在在 6.17 安装 gcc 后,测试发现 ld 路径还是用的 [ 工具链 ] 的

1. 不知道这个变化是怎么出现的?
2. 变化是否已经污染了编译环境?
3. 安装的 gcc 是否是正常的?是否要继续 LFS?

---

TOP


LFS 成功后再做一次编译呗……

TOP

从adjusting toolchain 重新来过

TOP