C 列出某个动态加载库的已用符号

我想列出程序从特定库加载的符号。您可以使用ldd列出所需的库：

    ldd -v myExecutable

这会产生如下输出：

    libgcc_s.so.1 (GCC_3.0) => /lib/i386-linux-gnu/libgcc_s.so.1
    libc.so.6 (GLIBC_2.1) => /lib/i386-linux-gnu/libc.so.6
    libc.so.6 (GLIBC_2.11) => /lib/i386-linux-gnu/libc.so.6
    libc.so.6 (GLIBC_2.1.3) => /lib/i386-linux-gnu/libc.so.6
    libc.so.6 (GLIBC_2.0) => /lib/i386-linux-gnu/libc.so.6

现在我想知道哪些符号是从哪个库加载的。具体地说，在我的例子中，我希望找到那些从GLIBC_2.11加载的，并最终摆脱它们

---

（我已经在使用以避免针对新符号进行链接-现在我想看看哪些符号在2.11之前不可用）

使用

LD\u DEBUG

环境变量。例如：

$ LD_USE_LOAD_BIAS=0 LD_DEBUG=all ls |& grep binding
 22160: binding file /lib64/libc.so.6 [0] to /lib64/libc.so.6 [0]: normal symbol `_res' [GLIBC_2.2.5]
 22160: binding file /lib64/libc.so.6 [0] to /lib64/libc.so.6 [0]: normal symbol `_IO_file_close' [GLIBC_2.2.5]
 22160: binding file /lib64/libc.so.6 [0] to /lib64/libc.so.6 [0]: normal symbol `stderr' [GLIBC_2.2.5]
 22160: binding file /lib64/libc.so.6 [0] to /lib64/libc.so.6 [0]: normal symbol `error_one_per_line' [GLIBC_2.2.5]
 22160: binding file /lib64/libc.so.6 [0] to /lib64/libc.so.6 [0]: normal symbol `__malloc_initialize_hook' [GLIBC_2.2.5]
 22160: binding file /lib64/libc.so.6 [0] to /lib64/ld-linux-x86-64.so.2 [0]: normal symbol `_dl_starting_up' [GLIBC_PRIVATE]
 22160: binding file /lib64/libc.so.6 [0] to /lib64/libc.so.6 [0]: normal symbol `__morecore' [GLIBC_2.2.5]
 22160: binding file /lib64/libc.so.6 [0] to /lib64/libc.so.6 [0]: normal symbol `__key_encryptsession_pk_LOCAL' [GLIBC_2.2.5]
 22160: binding file /lib64/libc.so.6 [0] to /lib64/libc.so.6 [0]: normal symbol `__progname_full' [GLIBC_2.2.5]
 22160: binding file /lib64/libc.so.6 [0] to /lib64/libc.so.6 [0]: normal symbol `__ctype32_tolower' [GLIBC_2.2.5]
 22160: binding file /lib64/libc.so.6 [0] to /lib64/libc.so.6 [0]: normal symbol `_environ' [GLIBC_2.2.5]
 22160: binding file /lib64/libc.so.6 [0] to /lib64/ld-linux-x86-64.so.2 [0]: normal symbol `_rtld_global' [GLIBC_PRIVATE]
 22160: binding file /lib64/libc.so.6 [0] to /lib64/libc.so.6 [0]: normal symbol `__progname' [GLIBC_2.2.5]
 22160: binding file /lib64/libc.so.6 [0] to /lib64/libc.so.6 [0]: normal symbol `argp_err_exit_status' [GLIBC_2.2.5]
 22160: binding file /lib64/libc.so.6 [0] to /lib64/libc.so.6 [0]: normal symbol `mallwatch' [GLIBC_2.2.5]
 22160: binding file /lib64/libc.so.6 [0] to /lib64/libc.so.6 [0]: normal symbol `__rcmd_errstr' [GLIBC_2.2.5]
 22160: binding file /lib64/libc.so.6 [0] to /lib64/libc.so.6 [0]: normal symbol `svcauthdes_stats' [GLIBC_2.2.5]
 22160: binding file /lib64/libc.so.6 [0] to /lib64/ld-linux-x86-64.so.2 [0]: normal symbol `__libc_enable_secure' [GLIBC_PRIVATE]
 [...]
 22160: binding file ls [0] to /lib64/libc.so.6 [0]: normal symbol `__libc_start_main' [GLIBC_2.2.5]
 22160: binding file ls [0] to /lib64/libc.so.6 [0]: normal symbol `strrchr' [GLIBC_2.2.5]
 22160: binding file ls [0] to /lib64/libc.so.6 [0]: normal symbol `setlocale' [GLIBC_2.2.5]
 22160: binding file ls [0] to /lib64/libc.so.6 [0]: normal symbol `bindtextdomain' [GLIBC_2.2.5]
 22160: binding file ls [0] to /lib64/libc.so.6 [0]: normal symbol `textdomain' [GLIBC_2.2.5]
 22160: binding file ls [0] to /lib64/libc.so.6 [0]: normal symbol `__cxa_atexit' [GLIBC_2.2.5]
 22160: binding file ls [0] to /lib64/libc.so.6 [0]: normal symbol `isatty' [GLIBC_2.2.5]
 22160: binding file ls [0] to /lib64/libc.so.6 [0]: normal symbol `getenv' [GLIBC_2.2.5]
 22160: binding file ls [0] to /lib64/libc.so.6 [0]: normal symbol `__ctype_b_loc' [GLIBC_2.3]
 22160: binding file ls [0] to /lib64/libc.so.6 [0]: normal symbol `__errno_location' [GLIBC_2.2.5]
 22160: binding file ls [0] to /lib64/libc.so.6 [0]: normal symbol `strtoul' [GLIBC_2.2.5]
 22160: binding file ls [0] to /lib64/libc.so.6 [0]: normal symbol `ioctl' [GLIBC_2.2.5]
 22160: binding file ls [0] to /lib64/libc.so.6 [0]: normal symbol `getopt_long' [GLIBC_2.2.5]
 22160: binding file ls [0] to /lib64/libc.so.6 [0]: normal symbol `malloc' [GLIBC_2.2.5]
 22160: binding file ls [0] to /lib64/libc.so.6 [0]: normal symbol `memcpy' [GLIBC_2.14]
 22160: binding file ls [0] to /lib64/libc.so.6 [0]: normal symbol `strlen' [GLIBC_2.2.5]
 22160: binding file ls [0] to /lib64/libc.so.6 [0]: normal symbol `opendir' [GLIBC_2.2.5]
 22160: binding file ls [0] to /lib64/libc.so.6 [0]: normal symbol `readdir' [GLIBC_2.2.5]
 22160: binding file ls [0] to /lib64/libc.so.6 [0]: normal symbol `closedir' [GLIBC_2.2.5]
 22160: binding file ls [0] to /lib64/libc.so.6 [0]: normal symbol `free' [GLIBC_2.2.5]
 22160: binding file ls [0] to /lib64/libc.so.6 [0]: normal symbol `_setjmp' [GLIBC_2.2.5]
 22160: binding file ls [0] to /lib64/libc.so.6 [0]: normal symbol `strcoll' [GLIBC_2.2.5]
 22160: binding file ls [0] to /lib64/libc.so.6 [0]: normal symbol `__ctype_get_mb_cur_max' [GLIBC_2.2.5]
 22160: binding file ls [0] to /lib64/libc.so.6 [0]: normal symbol `fwrite_unlocked' [GLIBC_2.2.5]
 22160: binding file ls [0] to /lib64/libc.so.6 [0]: normal symbol `exit' [GLIBC_2.2.5]
 22160: binding file ls [0] to /lib64/libc.so.6 [0]: normal symbol `__fpending' [GLIBC_2.2.5]
 22160: binding file ls [0] to /lib64/libc.so.6 [0]: normal symbol `fileno' [GLIBC_2.2.5]
 22160: binding file ls [0] to /lib64/libc.so.6 [0]: normal symbol `__freading' [GLIBC_2.2.5]
 22160: binding file ls [0] to /lib64/libc.so.6 [0]: normal symbol `fflush' [GLIBC_2.2.5]
 22160: binding file ls [0] to /lib64/libc.so.6 [0]: normal symbol `fclose' [GLIBC_2.2.5]

---

有关更多详细信息，请参阅

man ld。因此

nm

可能满足您的需求。只是在我的可执行文件上使用了它，它确实提供了库的版本以及符号。例如：

U tan@@GLIBC_2.0

---

因此，您可以执行grep以仅查找您感兴趣的版本。

尝试

nm/path/to/libc.so

。不过要小心-这将是一个相当长的列表，您可能希望通过管道将其传输到

更少的

。我不想列出库的符号，我想知道可执行文件使用了哪些符号。我想这问题很清楚！？这看起来很有希望，尽管输出似乎与ldd不一致：

LD_DEBUG=all myExec |&grep GLIBC_2.11

没有给出结果，但ldd说这是必要的。（我确实得到了其他版本的结果）@DanielS输出不完整，因为它是用

prelink

预链接的

LD\u USE\u LOAD\u BIAS=0

禁用预链接并允许查看所有绑定。我更新了答案。您的答案肯定显示了深刻的见解，但是，即使更新的答案也没有打印GLIBC_2.11依赖项。J20的答案正是我想要的，我发现execvpe@@GLIBC_2.11是一个令人不安的符号——因此我在输出中使用了“exec”，它给了我

execvp[GLIBC_2.2.5]

和

execv[GLIBC_2.2.5]

（而不是我使用的execvpe）——是不是execvpe在内部和内联使用的，因此实际上没有调用它，但仍然作为依赖项保留？无法添加有关

execvpe

的任何内容。在Fedora17上，它不是一个内联函数，所以我希望它出现在

ld.so

output中。无论如何，我想说

nm

和

LD_DEBUG

是两种互补而非排他性的方法。我第一次误读了这个答案，与Linuxios的评论类似，但实际上，

nm-myExec | grep-GLIBC_2.11

很有魅力！