为什么 ld-linux-x86-64.so.2 链接到意外位置？

Question

我在 debian 的/root/tools/ 中安装了一个新的 glibc，它已经预装了 glibc。为了测试新的 glibc，我输入：

gcc test.c -Wl,-rpath=/root/tools/lib -Wl,--dynamic-linker=/root/tools/lib/ld-linux-x86-64.so.2

产生a.out，然后输入：

ldd a.out

它显示

linux-vdso.so.1 (0x00007ffd1018c000)
libc.so.6 => /root/tools/lib/libc.so.6 (0x00007fc7f468b000)
/root/tools/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007fc7f4855000)

但是输入 ls -l /root/tools/lib/ld-linux-x86-64.so.2 , 它显示/root/tools/lib/ld-linux-x86-64.so.2 -> ld-2.33.so

为什么新 glibc 中的 ld.so 与 /lib64 中的 ld.so 链接？这要怎么解释？

Answer 1

然后输入：ldd a.out。

当存在多个 GLIBC 安装时，您应该停止使用 ldd -- 它会欺骗您。

相反，这样做：

env LD_TRACE_LOADED_OBJECTS=1 ./a.out

该命令将告诉您实际加载了哪些对象。

看起来你的设置是正确的，你只是被ldd误导了。

更新：

或者，使用 /root/tools/bin/ 中的 ldd 也可以显示正确的结果

是的，但这会显示错误的结果，例如/bin/date，所以ldd 会撒谎其他方式。

如果您已经知道哪个ldd 是正确的，那么您可以使用它。请注意，使用“错误”ldd 会产生令人困惑的输出。 LD_TRACE_LOADED_OBJECTS 不会受苦。