找回密码
 注册
查看: 2929|回复: 6

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

[复制链接]
发表于 2013-7-18 13:06:47 | 显示全部楼层 |阅读模式
各位兄台,chroot 之后,安装手册编译安装 gcc 后,编译 dummy.c 测试 ld 路径和手册的不一样:

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

手册中输出是:

  1. echo 'main(){}' > dummy.c
  2. cc dummy.c -v -Wl,--verbose &> dummy.log
  3. readelf -l a.out | grep ': /lib'
  4. [Requesting program interpreter: /lib/ld-linux.so.2]
复制代码
我执行 readelf -l a.out | grep ': /lib' 的输出是空,过滤 lib 关键字得到的位置:

  1. # readelf -l a.out | grep 'lib'
  2. [Requesting program interpreter: /tools/lib64/ld-linux-x86-64.so.2]
复制代码
后面还有一个 连接器 路径测试,这个输出是对的 :

  1. # grep found dummy.log
  2. found ld-linux-x86-64.so.2 at /lib64/ld-linux-x86-64.so.2
复制代码
其他所有 gcc 测试输出都合手册的一样的。

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

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

是否影响后面的继续?
发表于 2013-7-18 13:44:10 | 显示全部楼层
这次编译出来的程序,确实应该不再是连接到 /tools 才对。

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

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

使用道具 举报

 楼主| 发表于 2013-7-18 13:58:59 | 显示全部楼层
在之前调节工具链的那节。也有个类似的测试,我记得当时测试是何手册一样的。

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

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

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

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

使用道具 举报

发表于 2013-7-18 15:08:24 | 显示全部楼层
这节调整工具链的目的很明显
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 工具链。

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

加油,就快要脱离系统了
回复 支持 反对

使用道具 举报

 楼主| 发表于 2013-7-18 18:55:03 | 显示全部楼层

回复 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?

---
回复 支持 反对

使用道具 举报

发表于 2013-7-18 20:02:13 | 显示全部楼层

LFS 成功后再做一次编译呗……
回复 支持 反对

使用道具 举报

发表于 2013-7-18 22:18:43 | 显示全部楼层
从adjusting toolchain 重新来过
回复 支持 反对

使用道具 举报

您需要登录后才可以回帖 登录 | 注册

本版积分规则

GMT+8, 2021-12-1 02:49 , Processed in 0.080093 second(s), 15 queries .

© 2021 Powered by Discuz! X3.4.

快速回复 返回顶部 返回列表