除了Extend a dynamic linked shared library?之外，我还想了解如何获取一个封闭源代码共享库的所有公共方法的列表。
我试过了
nm -D libfoo.so
readelf -s libfoo.so
但我缺少诸如返回类型、参数等信息。
作为这个领域的初学者，我甚至不知道这些方法中的哪些可以为我的应用程序调用。
有没有更有用的工具？
编辑：
举个很简单的例子，我有以下几点：
libtest1.c：
int puts(char const *);
void libtest1()
{
puts("libtest1: called puts()");
}
然后我将libtest1.c编译为libtest1.so：
gcc -fPIC -shared -o libtest1.so libtest1.c
在我的“程序”（test.c）中，我使用共享库如下：
void libtest1(); //from libtest1.so
int main()
{
libtest1();
}
并编译test.c来测试：
gcc -o test test.c -ltest1 -ldl
虽然我没有libtest1.h可包含，但这是可行的。
它之所以“工作”，是因为我知道可能有一个libtest1（）方法要调用。
现在想想看，我失去了libtest1.c，只剩下libtest1.so在我手里，不记得方法有什么，它们需要什么参数。
这是个愚蠢的例子，我知道：）
或者作为另一个例子（也许更好）：
假设我发现了一个“libstone2goldconverter.so”在我的系统中的某个地方，然后想“天哪，我会用它的”。。但是怎么做呢？
最佳答案
共享库通常（如果不总是）提供包含公共API的头文件。
因此，与其直接从库中获取（公共）函数，不如尝试查找这些头文件，因为它们：
是编译应用程序所必需的
可能包含文档
包含开发人员希望的公共API
编辑
在你的例子中，你定义了
void libtest1();
这通常应该进入属于库的头文件。而不是你应该使用的定义：
#include "libtest1/public_api.h"
（或类似的东西，取决于库/头名称）
如果您“丢失”了头，那么库就变得“毫无价值”，因为您不再了解公共API，需要猜测（这显然是不需要的）。
之所以不使用头文件“just”有效，是因为您实际上知道函数的定义。编译器信任您的定义（因为它不知道您是否猜测了它），并接受它。当您要将对象文件链接到可执行文件时，链接器会尝试在库中查找对未定义函数的所有引用。在这个阶段，链接器会发现你的函数是否真的存在（用正确的参数和返回类型），如果不是，它会产生错误。
在
libstone2goldconverter.so的情况下，您应该很难找到附带的头文件（在您的系统、支持网站、通过电子邮件发送给作者等）。因为没有头文件就无法（正确地）使用库。这不仅适用于您（开发人员），也适用于库的所有者。因此，您可以确定头文件确实存在于某个地方。唯一的问题是：你的
libstone2goldconverter.so库看起来是私有的，库的作者/公司不太可能给你他们的头文件，因为这严重损害了他们的市场地位。。。；）