显示Linux上可执行文件使用的所有库
我想知道我的系统上的可执行文件使用哪些库。 更具体地说，我想排名使用哪些库最多，以及使用它们的二进制文件。 我怎样才能做到这一点？
（假设我们只是在谈论共享库）
- 使用
ldd列出每个可执行文件的共享库。 - 清理输出
- 按计数sorting，计算计数
要在“/ bin”目录中find所有可执行文件的答案：
find /bin -type f -perm /a+x -exec ldd {} \; \ | grep so \ | sed -e '/^[^\t]/ d' \ | sed -e 's/\t//' \ | sed -e 's/.*=..//' \ | sed -e 's/ (0.*)//' \ | sort \ | uniq -c \ | sort -n
将上面的“/ bin”更改为“/”以search所有目录。
输出（仅用于/ bin目录）将如下所示：
1 /lib64/libexpat.so.0 1 /lib64/libgcc_s.so.1 1 /lib64/libnsl.so.1 1 /lib64/libpcre.so.0 1 /lib64/libproc-3.2.7.so 1 /usr/lib64/libbeecrypt.so.6 1 /usr/lib64/libbz2.so.1 1 /usr/lib64/libelf.so.1 1 /usr/lib64/libpopt.so.0 1 /usr/lib64/librpm-4.4.so 1 /usr/lib64/librpmdb-4.4.so 1 /usr/lib64/librpmio-4.4.so 1 /usr/lib64/libsqlite3.so.0 1 /usr/lib64/libstdc++.so.6 1 /usr/lib64/libz.so.1 2 /lib64/libasound.so.2 2 /lib64/libblkid.so.1 2 /lib64/libdevmapper.so.1.02 2 /lib64/libpam_misc.so.0 2 /lib64/libpam.so.0 2 /lib64/libuuid.so.1 3 /lib64/libaudit.so.0 3 /lib64/libcrypt.so.1 3 /lib64/libdbus-1.so.3 4 /lib64/libresolv.so.2 4 /lib64/libtermcap.so.2 5 /lib64/libacl.so.1 5 /lib64/libattr.so.1 5 /lib64/libcap.so.1 6 /lib64/librt.so.1 7 /lib64/libm.so.6 9 /lib64/libpthread.so.0 13 /lib64/libselinux.so.1 13 /lib64/libsepol.so.1 22 /lib64/libdl.so.2 83 /lib64/ld-linux-x86-64.so.2 83 /lib64/libc.so.6
编辑 – 删除“grep -P”
我没有在我的ARM工具链上使用ldd，因此我使用了objdump：
$（CROSS_COMPILE）objdump -p
例如：
objdump -p /usr/bin/python: Dynamic Section: NEEDED libpthread.so.0 NEEDED libdl.so.2 NEEDED libutil.so.1 NEEDED libssl.so.1.0.0 NEEDED libcrypto.so.1.0.0 NEEDED libz.so.1 NEEDED libm.so.6 NEEDED libc.so.6 INIT 0x0000000000416a98 FINI 0x000000000053c058 GNU_HASH 0x0000000000400298 STRTAB 0x000000000040c858 SYMTAB 0x0000000000402aa8 STRSZ 0x0000000000006cdb SYMENT 0x0000000000000018 DEBUG 0x0000000000000000 PLTGOT 0x0000000000832fe8 PLTRELSZ 0x0000000000002688 PLTREL 0x0000000000000007 JMPREL 0x0000000000414410 RELA 0x0000000000414398 RELASZ 0x0000000000000078 RELAENT 0x0000000000000018 VERNEED 0x0000000000414258 VERNEEDNUM 0x0000000000000008 VERSYM 0x0000000000413534
要学习一个二进制文件使用的库，使用ldd
ldd path/to/the/tool
您必须编写一个小脚本才能进入系统故障。
在Linux上我使用：
lsof -P -T -p Application_PID
当可执行文件使用非默认加载器时，这比ldd更好
检查程序可执行文件的共享库依赖项
要找出一个特定的可执行文件所依赖的库，可以使用ldd命令。 该命令调用dynamic链接器来查找可执行文件的库依赖关系。
> $ ldd / path / to / program
请注意，不build议对任何不受信任的第三方可执行文件运行ldd，因为某些版本的ldd可能会直接调用可执行文件来标识其库依赖项，这可能会带来安全风险。
相反，显示未知应用程序二进制文件的库依赖性的更安全的方法是使用以下命令。
$ objdump -p / path / to / program | grep需要
获取更多信息
在UNIX系统上，假设二进制（可执行）名称是test。 然后我们使用下面的命令来列出在testing中使用的库
ldd test
使用ldd你可以得到工具使用的库。 要为一组工具排列库的用法，可以使用类似下面的命令。
ldd /bin/* /usr/bin/* ... | sed -e '/^[^\t]/ d; s/^\t\(.* => \)\?\([^ ]*\) (.*/\2/g' | sort | uniq -c
（在这里， sed去除所有不以标签开头的行，只过滤掉实际的库。使用sort | uniq -c你可以得到每个库的计数，指出它发生的次数。
您可能需要在结尾处添加sort -g以按使用顺序获取库。
请注意，使用上述命令可能会得到两行非库行。 一个静态可执行文件（“不是一个dynamic的可执行文件”）和一个没有任何库。 后者是linux-gate.so.1的结果，它不是文件系统中的一个库，而是一个由内核提供的库。
在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)
在这个例子中，使用which openssl填充给定可执行文件和当前用户环境的完全限定path。
在Ubuntu上打印与可执行文件相关的软件包
ldd executable_name | awk'{print $ 3}'| xargs dpkg -S | awk -F“：”'{print $ 1}'
readelf -drecursion
redelf -d产生与objdump -p类似的输出，这在以下url提到： https : redelf -d
但要注意，dynamic库可以依赖于其他dynamic库，因此你必须recursion。
例：
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
select一个，然后重复：
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>/maps来运行进程
这对于通过运行可执行文件来查找当前正在使用的所有库非常有用。 例如：
sudo awk '/\.so/{print $6}' /proc/1/maps | sort -u
显示所有当前加载的init （PID 1 ）的dynamic依赖关系：
/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
另见： https : //superuser.com/questions/310199/see-currently-loaded-shared-objects-in-linux/1243089
我发现这篇文章非常有帮助，因为我需要从第三方提供的库（32对64位执行path（s））调查依赖关系。
我根据RHEL 6发行版中的“readelf -d”build议，汇总了一个Q＆Drecursionbash脚本。
这是非常基本的，每次都会testing每个依赖项，即使它可能已经过testing（即非常冗长）。 输出也是非常基本的。
#! /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!!
将输出redirect到一个文件，grep for'find'或'失败'
使用和修改，当然，风险自负，如你所愿。
