c - 旧二进制文件上的 ldd 怪异

Question

我在 ldd 中遇到了以下奇怪的情况

$ sudo ldd ./monit 
    not a dynamic executable

$ readelf -d monit 

Dynamic section at offset 0x25ea90 contains 27 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libdl.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libpam.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libcrypt.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libresolv.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [libnsl.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
...

$ file ./monit 
./monit: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.0, with debug_info, not stripped

$ uname -r -i -m
4.15.0-43-generic x86_64 x86_64


$ file $(which ls)
/bin/ls: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=9567f9a28e66f4d7ec4baf31cfbf68d0410f0ae6, stripped

其他二进制文件和库是针对更新的内核/系统编译的，并且 ldd 成功报告了共享库，我想知道不同环境之间是否存在任何不兼容性，尽管这些二进制文件是在相同的体系结构上构建的..另一个愚蠢的问题是，如果某些共享库像 libpam 一样升级，那么在不插入旧库的情况下，二进制文件可能无法运行，api 是否可能会发生如此大的变化？如果新版本向后兼容，那么创建一个新的动态链接 (ln) 到旧名称还不够吗？

--最新--真是个白痴。我忘了我已经拒绝了该主机上分区的执行权限:(ldd 命令按预期工作

Answer 1

if there are any incompatibilities between different environment despite of the fact that the binaries are built on the same architecture

程序所依赖的“环境”是一个大词，是许多小东西放在一起的一个大词。它是一种体系结构(即CPU支持的指令集)或类似的体系结构(主板结构、CPU到内存结构等)或类似的操作系统细节(例如带有GNU扩展的POSIX兼容系统或带有dos的DOS系统) .h 库)。环境也是库版本，因为它们的 api 可以更改，并且也像环境变量(好吧，如果环境中存在这样的变量)。

知道“如果不同环境之间存在任何不兼容性”，您必须手动检查两个版本之间的所有更改。人们使用版本控制作为通知某些事情发生变化的可靠但糟糕的方式。然后，您必须查看文档，以人类可读的方式查看发生了什么变化。然后你必须查看源代码，看看到底发生了什么变化。

if some of the shared libraries would be upgraded like libpam, there would be chances that the binaries won't run without interposing the old libraries, is it likely that the api will be change so much?

首先请注意，大多数 UNIX 程序都遵循 GNU 许可证，该许可证规定:

THERE IS NO WARRANTY FOR THE PROGRAM

没有人会保证它在任何情况下都能工作。也就是说，可能是这样。可能不会。世界上有很多不同的库，它们是由不同的人编写的，而且它们都经常更改 api，所以它可能不起作用。它可能会起作用。这取决于。

为了确保 api 不会发生太大变化，聪明人写信给 standards 。和standards 。和standards 。和标准......

另一边是人们，即开发人员，他们免费完成所有这些艰苦的工作。他们需要更改 api，以便引入新的优秀功能或修复错误。所以他们稍微改变了 api。这可能会破坏依赖于该 api 的旧程序。

if the new releases was backward compatible, wouldn't be enough making a new dynamic link (ln) to the old name?

我这样做的次数比我愿意承认的要多(主要是用旧的 libpng 运行 eagle)，而且大多数情况下它都是有效的。试试吧，(通常，在正常的unix下，以用户身份运行，具有良好的权限)最糟糕的情况可能是你的程序会出现段错误(好吧，在sudo下可能发生的最糟糕的情况是对你的硬件造成永久性损坏并删除您的所有数据)。

大多数(不是全部)GNU/Linux 系统使用 glibc 作为 C 标准库的实现。这应该是最稳定的 api，因为所有 C 程序都依赖它。还有它changes too而且它并不总是向后兼容。