Linux libc.so.2是否需要位于/usr/lib中？

我有一个包含以下内容的目录：

bin/busybox
lib/ld-linux.so.2
lib/libc.so.6

当我调用：

chroot . bin/busybox sh

objcdump -p bin/busybox | grep NEEDED

它在以下情况下失败：

/bin/busybox: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory

当我将lib/libc.so.6移动到usr/lib时，它工作得很好

为什么libc必须在/usr/lib中？当我调用：

chroot . bin/busybox sh

objcdump -p bin/busybox | grep NEEDED

我得到：

NEEDED        libc.so.6

所以我想，因为只有库的soname没有斜杠等，所以加载的将能够在标准文件夹中找到它，即/lib和/usr/lib。显然，情况并非如此

为了让事情变得更加混乱，ld linux.so.2似乎必须在/lib中，因为当它移动到/usr/lib时，chroot会失败，原因是：

chroot: failed to run command '/bin/busybox': No such file or directory

我了解到这实际上是一个无法找到加载程序的错误，而不是busybox二进制文件

---

libc.so.2发行版的问题是特定的吗？如果这很重要，我使用的是Arch Linux。

加载程序的位置（通常类似于

/lib/ld Linux.so

）是二进制硬编码的。这个组件没有搜索过程-如果找不到它，二进制文件将根本不会运行

（具体路径取决于您使用的libc和体系结构。例如，位于x86_64上的glibc的

/lib64/ld-linux-x86-64.so.2

）

---

将搜索动态库的位置可在

/etc/ld.so.conf

中配置。但是，如果chroot中没有该文件，则可能无法配置某些标准路径

编译时设置LD_RUN_PATH，或者在运行前导出LD_library_PATH来设置库搜索路径，或者执行ln-s/lib/libc.so.6/usr/lib/libc.so.6谢谢。这些都是解决问题的方法（除了将文件保存在目录中以便所有文件都能正常工作之外），但不解释原始行为。硬编码加载程序是否存储在.interp头部分？我认为.interp secion实际上有加载程序代码。是的，我没有ld.so.conf。我认为/lib和/usr/lib是默认的默认值；即使未定义任何其他内容，d.e.仍在使用中。加载程序的路径存储在

.interp

部分，而不是加载程序的代码中。（在我的系统中，加载程序在磁盘上大约有150K，这对于包含在每个二进制文件中来说是相当大的！）我被man 8 ld的措辞弄糊涂了。因此：（…）存储在.interp部分的动态链接器（…）我读到链接器可能被任意代码替换，这就是为什么在未经测试的二进制文件上调用ldd可能是危险的。这种更换是否只是更换装载机的位置？它接受相对路径吗？