这个问题很老了，其他答案也很老了。Employed Russian 的答案 非常好，信息量很大，但只有当您有源代码时才有效。如果没有，当时的替代方案非常棘手。幸运的是，现在我们有一个简单的解决方案（如 他的一个回复 ），使用 patchelf 。您所要做的就是：

$ ./patchelf --set-interpreter /path/to/newglibc/ld-linux.so.2 --set-rpath /path/to/newglibc/ myapp

这将使无法正常工作的可执行文件使用不同的链接器路径。之后，你就可以执行文件了：

$ ./myapp

，无需 chroot 手动编辑二进制文件。但是，如果您不确定自己在做什么，请记住在修补二进制文件之前备份它，因为它会修改二进制文件。修补后，您无法将旧路径恢复为解释器/rpath。如果它不起作用，您将不得不继续修补它，直到找到真正有效的路径……好吧，它不必是一个反复试验的过程。例如，在 OP 的例子中，他需要 GLIBC_2.3 ，因此您可以使用轻松找到哪个库提供该版本 strings ：

$ strings /lib/i686/libc.so.6 | grep GLIBC_2.3
$ strings /path/to/newglib/libc.so.6 | grep GLIBC_2.3

理论上，第一个 grep 会输出空，因为系统 libc 没有他想要的版本，而第二个 grep 应该输出 GLIBC_2.3，因为它有他 myapp 想要的版本，所以我们知道我们可以 patchelf 使用该路径来执行二进制文件。如果遇到分段错误，请阅读最后的说明。

当您尝试在 Linux 中运行二进制文件时，二进制文件会尝试加载链接器（又名加载器，又名解释器），然后加载库，它们都应该在路径中和/或正确的位置。如果您的问题出在链接器上，并且您想找出二进制文件正在寻找的路径，您可以使用以下命令查找：

$ readelf -l myapp | grep interpreter
  [Requesting program interpreter: /lib/ld-linux.so.2]                                                                                                                                                                                   

如果您的问题与库有关，则可以使用以下命令为您提供正在使用的库：

$ readelf -d myapp | grep Shared
$ ldd myapp 

这将列出二进制文件所需的库，但您可能已经知道有问题的库，因为它们已经产生错误，就像 OP 的情况一样。执行 patchelf 后，可能 myapp 仍然无法正常工作，运行时 ldd myapp 它会列出具有混合路径的库，一些到您设置的路径，其他到原始系统路径。那是因为您的路径没有这些库。 rpath 将在您设置的路径中搜索库，但如果不存在，它仍会在其他系统位置中查找。在这种情况下，如果您在某处有缺失的库，只需将其复制到您 rpath 选择的路径，它应该就可以工作了。

\'patchelf\' 可以解决您在尝试运行程序时可能遇到的许多不同问题，这些问题与这两个问题有关。例如，如果您得到： ELF file OS ABI invalid ，则可以通过设置新的加载器（ --set-interpreter 命令的一部分）来修复，如我 在此处 运行存在且可执行的文件时 No such file or directory 出现的问题 处 。在那个特定情况下，OP 缺少加载器的链接，但也许在您的情况下您没有 root 访问权限并且无法创建链接。设置新的解释器将解决您的问题。

感谢 Employed Russian 和 Michael Pankov 的见解和解决方案！

注意 事项：您可能会遇到使用多个库的情况 myapp ，其中大多数都正常，但有些不正常；然后您 patchelf 将其移至新目录，就会出现分段错误。当您 patchelf 编写二进制文件时，您会更改几个库的路径，即使有些库最初位于不同的路径中。请看下面的示例：

$ ldd myapp
./myapp: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by ./myapp)
./myapp: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by ./myapp)
        linux-vdso.so.1 =>  (0x00007fffb167c000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f9a9aad2000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f9a9a8ce000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f9a9a6af000)
        libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f9a9a3ab000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f9a99fe6000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f9a9adeb000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f9a99dcf000)

请注意，大多数库都在 中， /lib/x86_64-linux-gnu/ 但有问题的库 ( libstdc++.so.6 ) 在 上 /usr/lib/x86_64-linux-gnu 。在我将其修补 myapp 以指向 /path/到/mylibs ，我得到了分段错误。出于某种原因，这些库与二进制文件并不完全兼容。由于 myapp 没有抱怨原始库，我将它们从 复制 /lib/x86_64-linux-gnu/ to /path/to/mylibs2 ，我也 libstdc++.so.6 从 /path/to/mylibs 那里复制。然后我将其修补到 /path/to/mylibs2 ， myapp 现在可以正常工作。如果您的二进制文件使用不同的库，并且您有不同的版本，则可能无法修复您的情况。 :( 但如果可能的话，混合使用库可能是办法。这不是理想的，但 也许 会起作用。祝你好运！