Take the 2-minute tour ×

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?


For a very simple example, I have following:


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()

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?

share|improve this question
If you find the headers for libstone2goldconverter.so please let me know! :D –  Veger Jan 23 '13 at 15:29
If you really need to attempt this without the header file, the problem is essentially the same as reverse engineering machine (assembly) code. Which is to say, hard, and automatic tools can only do some of the work. –  aschepler Jan 23 '13 at 15:36
I'm sure I will find the header files for my case, but it would have been more easy if there were other ways to figure out the api. I will let you know, veger ;) –  Martin M. Jan 23 '13 at 15:40
add comment

2 Answers

up vote 2 down vote accepted

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

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... ;)

share|improve this answer
I agree with you that there should be a header file, but I will add a small example to my question in the next minutes.. –  Martin M. Jan 23 '13 at 15:07
Okay, thank you (both) for the detailed informations. I will accept Veger's answer because it's more "complex", but also upvote the other one. –  Martin M. Jan 23 '13 at 15:35
add comment

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.)


(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.)

share|improve this answer
And even in C++, there's usually no way to tell from a library whether or not a function or method is supposed to be exposed as "public". –  aschepler Jan 23 '13 at 14:54
add comment

Your Answer


