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

if_else

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

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

手册中输出是：

1. 
   
2. echo 'main(){}' > dummy.c
   
3. cc dummy.c -v -Wl,--verbose &> dummy.log
   
4. readelf -l a.out | grep ': /lib'
   
5. [Requesting program interpreter: /lib/ld-linux.so.2]
   

复制代码

我执行 readelf -l a.out | grep ': /lib' 的输出是空，过滤 lib 关键字得到的位置：

1. 
   
2. # readelf -l a.out | grep 'lib'
   
3. [Requesting program interpreter: /tools/lib64/ld-linux-x86-64.so.2]
   

复制代码

后面还有一个 连接器 路径测试，这个输出是对的 ：

1. 
   
2. # grep found dummy.log
   
3. found ld-linux-x86-64.so.2 at /lib64/ld-linux-x86-64.so.2
   

复制代码

其他所有 gcc 测试输出都合手册的一样的。

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

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

是否影响后面的继续？

jiangtao9999

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

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

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

if_else

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

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

    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 还是其他的程序需要重新再编译安装一遍？

zy_sunshine

这节调整工具链的目的很明显
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 工具链。

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

加油，就快要脱离系统了

if_else

----


问题是出现在调整工具链之后，编译安装 LFS 的 gcc 后（6.17. GCC-4.7.2 ）的 test ：

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

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

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

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

---

jiangtao9999

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

zy_sunshine

从adjusting toolchain 重新来过