Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a problem with a library I'm working with for the first time ( it's Boost.Python but my question is much more general than this case).

As a consequence I need to check what is the interface of the library I have built: so as to check if I have at least built everything correctly.

(Python is complaining that he doesn't see my module, though I put the .so renammed in .pyd into its PYTHONPATH, so there's something wrong in my library)

I need to know all the names of the exposed functions of my .so library, and their prototype if possible.

Are there commands or package that I could install to achieve something like this ?

share|improve this question
up vote 3 down vote accepted

You can get information from an ELF file (executable or library) with readelf.

Looks like you're looking for the exported symbols, so use:

$ readelf --dyn-syms libyourthing.so

For C-type functions, you'll only get function names, not argument types or return values. For C++ functions, you'll get mangled names - pipe the output of that command through c++filt to get function names and argument types (still no return values though).
(Globals are also displayed in the output, with their names and size but not their type.)

Other useful tools are nm and objdump which provide similar information.

I'm not sure that'll help you though. You should also try strace to see if python is looking where you think it is. Something like:

$ strace -e trace=open python your_code_that_loads_your_lib.py

will show you all the open calls executed by python - look for your library name in there (there will be a lot logged by the above, filter it). Each call also shows the return code, so you might get a better idea about what is going on.

Oh, and do make sure you're not trying to load a 32bit library into a 64bit python runtime, or vice-versa.

share|improve this answer
It will always help another time I need to check the interface of my library. You were right it doesn't help me as is tonight, but at least I see a hundred of boost.python stuff exposed. I'm gonna check strace. – Stephane Rolland Jan 20 '13 at 21:14

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.