如果你只是想知道是否有符号存在，你可以使用

objdump -h /path/to/object

或者列出调试信息

objdump -g /path/to/object

如果你的.so文件是elf格式的，你可以使用readelf程序从二进制文件中提取符号信息。这个命令会给你一个符号表:

readelf -Ws /usr/lib/libexample.so

你应该只提取在这个.so文件中定义的，而不是在它引用的库中。在本例中，第七列应该包含一个数字。你可以使用一个简单的正则表达式来提取它:

readelf -Ws /usr/lib/libstdc++.so.6 | grep '^\([[:space:]]\+[^[:space:]]\+\)\{6\}[[:space:]]\+[[:digit:]]\+'

或者如卡斯平所提议的:

readelf -Ws /usr/lib/libstdc++.so.6 | awk '{print $8}';

列出符号的标准工具是nm，你可以这样简单地使用它:

nm -gD yourLib.so

如果你想看到c++库的符号，添加“-C”选项，它需要这些符号(它的可读性要强得多)。

nm -gDC yourLib.so

如果你的.so文件是elf格式的，你有两个选择:

objdump (-C也可用于调用c++):

$ objdump -TC libz.so

libz.so:     file format elf64-x86-64

DYNAMIC SYMBOL TABLE:
0000000000002010 l    d  .init  0000000000000000              .init
0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 free
0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 __errno_location
0000000000000000  w   D  *UND*  0000000000000000              _ITM_deregisterTMCloneTable

或者使用readelf:

$ readelf -Ws libz.so
Symbol table '.dynsym' contains 112 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND
     1: 0000000000002010     0 SECTION LOCAL  DEFAULT   10
     2: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND free@GLIBC_2.2.5 (14)
     3: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __errno_location@GLIBC_2.2.5 (14)
     4: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND _ITM_deregisterTMCloneTable

对于Android .so文件，NDK工具链附带了其他答案中提到的所需工具:readelf, objdump和nm。

尝试在nm标志中添加-l，以获得每个符号的源。如果库是用调试信息(gcc -g)编译的，这应该是源文件和行号。正如Konrad所说，在这一点上，对象文件/静态库可能是未知的。

我一直在想为什么-fvisibility=hidden和#pragma GCC可见性似乎没有任何影响，因为所有的符号都是用nm可见的-直到我发现这篇文章指向readelf和objdump，这让我意识到似乎实际上有两个符号表:

你可以用nm列出来 你可以用readelf和objdump列出

我认为前者包含可以用strip或-s开关剥离的调试符号，可以给链接器或安装命令。即使nm不再列出任何东西，导出的符号仍然会被导出，因为它们在ELF“动态符号表”中，也就是后者。