0

I am building/using the python module for LAMMPS, which is the open source Molecular Dynamics simulator (project home, source).

The python module works by compiling the C++ application as a library, and using CDLL/ctypes to call a C function interface. When you call the CDLL() function in python, the load fails if there are any missing symbols that the OS doesn't find in the library itself, and can't load from other available libraries.

The particular symbol I'm getting as missing is a C++ mangled name __ZN3MPI3Win14Set_errhandlerERKNS_10ErrhandlerE, which is probably MPI_Win_set_errhandler (or some namespaced/object oriented equivilent with a similar name). For context, I've compiled it using the python/setup_serial.py file, which should build with a dummy MPI interface, and shouldn't reference any real MPI symbols at all; so this is a rogue reference that's crept in somewhere. I've also made some modifications to the source, but I get the same error when I disable all my changes.

My question is, what is the best debugging strategy for finding out where a symbol is referenced in a dynamic library giving this sort of error? So far, I've tried searching the source for references to this symbol (or parts of the name,) but I'm not finding any instances (in fact, the only results are the binary files from the python build process, of the library I'm having trouble importing.)

My next step is to search inside the binary somehow, I guess, but I have no idea where to begin that (or some other strategy).

tehwalrus
  • 2,589
  • 5
  • 26
  • 33

1 Answers1

2

c++filt is your friend

$ c++filt __ZN3MPI3Win14Set_errhandlerERKNS_10ErrhandlerE
MPI::Win::Set_errhandler(MPI::Errhandler const&)

Now do a quick google search on that library http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=512616

Looks like there is a case where parts are upgraded but not recompiled. The second thing is to look at the link line for the complier and see what libraries it includes.

Final last resort is to do something like:

readelf -s /path/to/libfoo.so

And start grepping around to see if it's defined somewhere.

koblas
  • 25,410
  • 6
  • 39
  • 49
  • The link line is very very long, but I've checked and it does include the link to the dummy C MPI api found under `src/STUBS/` (relative to the project root). I'm not sure I understand why un-inlining a function in the official MPI distribution would break a local dummy version of the API - unless I'm referencing an official MPI header file that's now changed. – tehwalrus Apr 27 '12 at 22:13
  • I've checked my system folders, and there is an mpi.h, but it's for version 1.2.8 - before the trouble started on the debian thread, so even if that was overriding the local header file it shouldn't be breaking things. – tehwalrus Apr 27 '12 at 22:20
  • the only thing to add would be that you need to use `gobjdump` (under macports' binutils package) on OS X, as readelf is linux-only [see here](http://stackoverflow.com/questions/3286675/readelf-like-tool-for-mac-os-x), but otherwise this is a very good roundup of the required tools. Thanks! :) – tehwalrus Apr 27 '12 at 22:54