2

In addition to Extend a dynamic linked shared library? I would like to find out, how I can get a list of all public methods of a shared library with closed source.

I have tried 

nm -D libfoo.so
readelf -s libfoo.so

but there I'm missing informations like return type, arguments etc.

As a beginner in this area, I can't even figure out what of those methods would be callable for my application.

Has anyone a more helpful tool?

EDIT:

For a very simple example, I have following:

libtest1.c:

int puts(char const *);

void libtest1()
{
    puts("libtest1: called puts()");
}

Then I compiled libtest1.c to libtest1.so:

gcc -fPIC -shared -o libtest1.so libtest1.c

In my "program" (test.c) I use the shared library as following:

void libtest1();  //from libtest1.so

int main()
{
    libtest1();
}

And compile test.c to test:

gcc -o test test.c -ltest1 -ldl

This will work although I have NO libtest1.h to include. It works "just" because I know that there might be a libtest1()-method to call.

Now think of I lost libtest1.c and just have the libtest1.so in my hands and don't remember what there are for methods and what params do they need.

That's a stupid example, I know :)

Or as an other example (maybe better):

Let's assume I found a "libstone2goldconverter.so" somewhere in my system and think "oh my god, I will use it".. but how?

4

2 回答 2

2

There's no way to find out the information you want from a C library - the information is destroyed by the compiler. (You can somewhat do it with C++, but not with C.)

Sorry!

(Veger is right that you should have been given a header file along with the library, which is what's supposed to tell you this information.)

于 2013-01-23T14:49:27.677 回答
2

A shared library usually (if not always) provides header files containing the public API.

So, instead of trying to grab (public) function directly from the library, you should try to find these header files, because they:

  • are required for compiling your application
  • might contain documentation
  • contain the public API as intended by the developer

EDIT
In you example you define

void libtest1();

This should typically go into the header files belonging to the library. And instead of the definition you should use:

#include "libtest1/public_api.h"

(or something similar, depending on your library/header names)

If you 'lose' the header then the library becomes 'worthless', as you do not know the public API anymore and need to guess (which is obviously undesired).

The reason why, not using a header file, 'just' works, is because you actually know the definition of the function. The compiler trusts your definition (as it does not know whether you guessed it or not) and accepts it. When you are going to link your object files into the executable, the linker tries to find all references to undefined function in libraries. During this stage the linker finds out whether your function actually exists (with the correct parameters and return type), if not it will generate an error.

In the case of libstone2goldconverter.so you should look really hard to find the accompanying header files (on your system, supporting website, by emailing the author, etc.). As there is no way you can use the library (properly) without the header files.

This goes not only for you (the developer), but also for the owner of the library. So, you can be certain that the header files do exists somewhere. Only thing is: your libstone2goldconverter.so library look proprietary and the author/company of the library is not likely to give you their header files, as it severely compromises their marketing position... ;)

于 2013-01-23T14:50:13.120 回答