Hi Peter,

I've no idea whether this is related, but I believe MacOSX 10.9 uses a different implementation of the C++ standard library than previous versions. Perhaps your module is trying to load the new library and getting different symbols??


On 8 November 2013 19:55, Peter Eastman <peastman@stanford.edu> wrote:
I just upgraded to OS X 10.9, and my SWIG generated Python module can no longer be loaded.  When I try to import the module, it fails with the following error:

ImportError: dlopen(/Library/Python/2.7/site-packages/simtk/openmm/_openmm.so, 2): Symbol not found: __ZN6OpenMM13CustomGBForce11addFunctionERKNSt3__112basic_stringIcNS1_11char_traitsIcEENS1_9allocatorIcEEEERKNS1_6vectorIdNS5_IdEEEEdd

Indeed, there is no such symbol in the original library SWIG created the wrapper for.  Instead the actual symbol (as shown by the nm command) is


Running those through demangler.com translates them as

OpenMM::CustomGBForce::addFunction(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, std::__1::vector<double, std::__1::allocator<double> > const&, double, double)


OpenMM::CustomGBForce::addFunction(std::string const&, std::vector<double, std::allocator<double> > const&, double, double)

respectively.  And here's the signature of the original C++ method:

int addFunction(const std::string& name, const std::vector<double>& values, double min, double max);

So somehow, the SWIG generated library is mangling the symbol name incorrectly, preventing it from getting loaded at runtime.  I'm at a loss for what's going on.  And this worked correctly on earlier OS versions.  Can anyone provide insight on this?


November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
Swig-devel mailing list