以下是我遇到的情况：
我创build了一个debootstrap ubuntu特立独行（64位）环境。 我把它放在我的ubuntu（64位）清晰系统上的/env/mav/上。 我可以chroot进入/env/mav并且可以完美地利用一个特立独行的系统。
我甚至可以在chrooted环境外使用清晰的程序。 那就是/env/mav/bin/ls会运行。
但是，我注意到如果我修改LD_LIBRARY_PATH为/env/mav/lib [1] [2]
我运行的每一个程序（清醒和特立独行）都会立即崩溃。 （例如，ls导致段错误）。 kern.log显示：
segfault at 7fece284aa18 ip 00007fece284aa18 sp 00007fff32028158 error 15
但是，显然如果我chroot到/env/mav ，每个程序运行良好。 并不是所有的库只是从jailed（ /env/mav ） /lib读取？ 那么在这种情况下chroot和修改LD_LIBRARY_PATH什么区别呢？
而且，如果我：
mount -B /env /env/mav/env
然后chroot /env ，然后将LD_LIBRARY_PATH设置为/env/mav/lib ，一切仍然正常运行。
我对这里发生的事情感到不知所措。 有一些ld内部存储在某个地方吗？ chroot做一些神奇的事情吗？
[1]用例是从特定的环境中正确地运行程序到特立独行的jail以外的dynamic链接库。
[2]这只是一个简略的例子。 实际上/usr/lib等都包含在内。 包括特立独行的环境/ lib“毒药”的一切; 使用其他特立独行者库目录没有问题。
LD_LIBRARY_PATH是ld-linux.so程序/库的选项。 这个库是一个dynamick链接器。 它的路径是“ /lib/ld-linux.so.2 ”，在ELF头文件（INTREP字段）中，在几乎所有的动态链接的程序中被硬编码。 我的意思是，当Linux内核运行二进制文件时，对LD_LIBRARY_PATH的特殊含义一无所知。
所以，当你跑步
LD_LIBRARY_PATH=/env/mav/ /env/mav/bin/ls
将使用根系统的/lib/ld-linux.so.2，然后尝试使用$LD_LIBRARY_PATH env变量来解析动态库（可以使用LD_DEBUG=all env变量来查看goind的内容）
而当你做一个chroot时，会使用特立独行的/lib/ld-linux.so.2 。
我认为，主机系统的ld-linux和guest（maverick）系统的libc.so （因为ld-linux是glibc / eglibc包的一部分，它使用libc.so中的某些东西）可能会有一些不兼容的地方。
为了测试我的假设，试着运行（env变量设置的bash语法）：
LD_LIBRARY_PATH=/env/mav/ /env/mav/lib/ld-linux.so.2 /env/mav/bin/ls
在这里，我尝试手动启动guest虚拟机的ld-linux，以覆盖INTREP硬编码路径（是的，运行.so库似乎相当不寻常，但是这个库是非常特殊的情况并且允许这种语法）。 如果这个命令行得通，我的假设可能是好的。 如果没有，还有其他解释可能。