ldd在dynamic链接的二进制文件上不起作用

我有一个使用一堆.so文件的二进制文件。

bash-3.00$ file foo foo: ELF 32-bit LSB executable,Intel 80386,version 1 (SYSV),for GNU/Linux 2.6.21,dynamically linked (uses shared libs),not stripped

但是，如果我在这个文件上运行ldd，那么它就无法获取二进制文件依赖的.so文件。

bash-3.00$ ldd foo not a dynamic executable bash-3.00$

readelf确实显示二进制文件使用的共享库列表

bash-3.00$ readelf -d foo Dynamic segment at offset 0x17c810 contains 70 entries: Tag Type Name/Value 0x00000001 (NEEDED) Shared library: [libdl.so.2]

为什么ldd在这种情况下无法获取库依赖关系？

加载boost的共享库时出错

在加载perl模块之前修改ld.sopath

在Linux上pipe理共享库的常用方法是什么？

如何使用gcc在ubuntu下从静态库中创build共享库

如何通过系统库强制使用本地共享库？

Linux共享库的init和deinit也使用c ++静态初始化

gcc在指定的path中链接共享库，但不在标准path中

关于共享库的问题

在Linux中共享可执行的内存页面？

Linux，共享库使用主程序中的函数而不是其他共享库

就像其中一个评论所说 – 你试过在64位系统上使用ldd来检查一个32位的ELF对象。 ldd使用标准的动态链接器来跟踪依赖关系，所以如果你的平台没有被检查的ELF对象所需的链接器，ldd将会失败。 在这些情况下，Readelf和objdump更加健壮。

请注意，在Fedora 21中，为了让ldd识别32位.so文件，我必须安装以下内容：

sudo yum install glibc.i686 libgcc.i686 libstdc++.i686 glibc-devel.i686

我不确定哪一个修复了我在ldd中看到的“不是动态的可执行文件”错误。