其他答案忽略了一个重要的问题:

共享库既可以直接链接，也可以通过另一个库间接链接。

仅适用于直接链接:

objdump——private-headers "${bin}" | grep 'NEEDED' | cut——delimiter=' ' ' ——字段= 18岁

所有:

LDD "${bin}" | cut——fields=2 | cut——delimiter=' '——fields=1 | rev | cut——delimiter='/'——fields=1 | rev | sort——unique——version-sort

我发现这篇文章非常有用，因为我需要调查来自第三方提供的库的依赖关系(32位执行路径vs 64位执行路径)。

我在RHEL 6发行版上基于'readelf -d'建议组合了一个Q&D递归bash脚本。

它是非常基本的，每次都会测试每个依赖项，即使之前可能已经测试过了(即非常冗长)。输出也是非常基本的。

#! /bin/bash

recurse ()
# Param 1 is the nuumber of spaces that the output will be prepended with
# Param 2 full path to library
{
#Use 'readelf -d' to find dependencies
dependencies=$(readelf -d ${2} | grep NEEDED | awk '{ print $5 }' | tr -d '[]')
for d in $dependencies; do
   echo "${1}${d}"
   nm=${d##*/}
   #libstdc++ hack for the '+'-s
   nm1=${nm//"+"/"\+"}
   # /lib /lib64 /usr/lib and /usr/lib are searched
   children=$(locate ${d} | grep -E "(^/(lib|lib64|usr/lib|usr/lib64)/${nm1})")
   rc=$?
   #at least locate... didn't fail
   if [ ${rc} == "0" ] ; then
      #we have at least one dependency
      if [ ${#children[@]} -gt 0 ]; then
         #check the dependeny's dependencies
         for c in $children; do
          recurse "  ${1}" ${c}
         done
      else
         echo "${1}no children found"
      fi
   else
      echo "${1}locate failed for ${d}"
   fi
done
}
# Q&D -- recurse needs 2 params could/should be supplied from cmdline
recurse "" !!full path to library you want to investigate!!

将输出重定向到一个文件并grep 'found'或'failed'

使用和修改，当然风险由你自己承担，如你所愿。

Readelf -d递归

Redelf -d产生与objdump -p类似的输出，objdump -p在https://stackoverflow.com/a/15520982/895245中提到过

但要注意动态库可能依赖于其他动态库，因此必须递归。

例子:

readelf -d /bin/ls | grep 'NEEDED'

示例ouptut:

 0x0000000000000001 (NEEDED)             Shared library: [libselinux.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libacl.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]

然后:

$ locate libselinux.so.1
/lib/i386-linux-gnu/libselinux.so.1
/lib/x86_64-linux-gnu/libselinux.so.1
/mnt/debootstrap/lib/x86_64-linux-gnu/libselinux.so.1

选择一个，然后重复:

readelf -d /lib/x86_64-linux-gnu/libselinux.so.1 | grep 'NEEDED'

样例输出:

0x0000000000000001 (NEEDED)             Shared library: [libpcre.so.3]
0x0000000000000001 (NEEDED)             Shared library: [libdl.so.2]
0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
0x0000000000000001 (NEEDED)             Shared library: [ld-linux-x86-64.so.2]

等等。

/proc/<pid>/正在运行进程的映射

这对于查找当前正在运行的可执行文件所使用的所有库非常有用。例如:

sudo awk '/\.so/{print $6}' /proc/1/maps | sort -u

显示init (PID 1)当前加载的所有动态依赖项:

/lib/x86_64-linux-gnu/ld-2.23.so
/lib/x86_64-linux-gnu/libapparmor.so.1.4.0
/lib/x86_64-linux-gnu/libaudit.so.1.0.0
/lib/x86_64-linux-gnu/libblkid.so.1.1.0
/lib/x86_64-linux-gnu/libc-2.23.so
/lib/x86_64-linux-gnu/libcap.so.2.24
/lib/x86_64-linux-gnu/libdl-2.23.so
/lib/x86_64-linux-gnu/libkmod.so.2.3.0
/lib/x86_64-linux-gnu/libmount.so.1.1.0
/lib/x86_64-linux-gnu/libpam.so.0.83.1
/lib/x86_64-linux-gnu/libpcre.so.3.13.2
/lib/x86_64-linux-gnu/libpthread-2.23.so
/lib/x86_64-linux-gnu/librt-2.23.so
/lib/x86_64-linux-gnu/libseccomp.so.2.2.3
/lib/x86_64-linux-gnu/libselinux.so.1
/lib/x86_64-linux-gnu/libuuid.so.1.3.0

这个方法还显示了用dlopen打开的库，在Ubuntu 18.04上用sleep(1000)进行了测试。

参见:https://superuser.com/questions/310199/see-currently-loaded-shared-objects-in-linux/1243089

检查程序可执行文件的共享库依赖关系

要找出特定可执行文件所依赖的库，可以使用ldd命令。这个命令调用动态链接器来查找可执行文件的库依赖关系。

>$ldd /path/to/program

注意，不建议使用任何不受信任的第三方可执行文件运行ldd，因为某些版本的ldd可能直接调用可执行文件来识别其库依赖关系，这可能存在安全风险。

相反，更安全的显示未知应用程序二进制程序的库依赖关系的方法是使用以下命令。

$ objdump -p /path/to/program | grep需要

更多信息

在UNIX系统上，假设二进制(可执行)名称为test。然后我们使用下面的命令列出测试中使用的库

ldd test

在OS X上默认没有ldd, objdump或lsof。作为替代，尝试otool -L:

$ otool -L `which openssl`
/usr/bin/openssl:
    /usr/lib/libcrypto.0.9.8.dylib (compatibility version 0.9.8, current version 0.9.8)
    /usr/lib/libssl.0.9.8.dylib (compatibility version 0.9.8, current version 0.9.8)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)

在本例中，使用哪个openssl填充给定可执行文件和当前用户环境的完全限定路径。