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

问题描述

我在 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 ？如何解释？

解决方法

然后输入：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 不会受到影响。