You are correct that it doesn't seem to be linked against libpython (in contrast to Linux); I have the same:
- Code: Select all
% otool -L /usr/local/lib/python2.7/site-packages/IcePy.so
/usr/local/lib/python2.7/site-packages/IcePy.so:
/usr/local/lib/python2.7/site-packages/IcePy.35.so (compatibility version 0.0.0, current version 0.0.0)
@rpath/libIce.35.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libSlice.35.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libIceUtil.35.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/local/Frameworks/Python.framework/Versions/2.7/Python (compatibility version 2.7.0, current version 2.7.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)
Looking at the needed symbols, with "nm -u", you can see a bunch of python symbols to be provided by the interpreter. Other than making sure it's built against the correct libpython, to ensure the symbols are all satisfied, it's difficult to see what else is wrong.
One potential thing to check is whether you're building Ice with the same compiler/libstdc++ as was used to build anaconda python. For example, if it's using gcc from MacOS 10.8 (clang wrapper with libstdc++) that's not going to be link-compatible with clang++ with libc++ with MacOS 10.9/10.10. Since Python is C-only, it shouldn't be a problem, but might be something worth checking.
I would also suggest looking at each undefined symbol above, and then comparing with what's defined in the libpython used by your interpreter e.g. with:
- Code: Select all
% otool -L /usr/local/bin/python
/usr/local/bin/python:
/usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/Python (compatibility version 2.7.0, current version 2.7.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)
% nm /usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/Python
I've seen issues with "import IcePy" before, particularly on Windows, and these were always due to a ABI incompatibility preventing the module load, or the Ice DLLs not being on the search path.
May also be worth checking: are the Ice .dylibs on your DYLD_LIBRARY_PATH if they aren't on the standard search path?
Kind regards,
Roger