tags:

views:

371

answers:

1

Hi,

Trying to load a shared lib out of the current '.' dir in a unit test on osx.

What works on Linux and Netbsd there is a symlink _mymodule.so --> ../.libs/libmymodule.so

but on osx, python's import mymodule won't find

_mymodule.dylib --> ../.libs/libmymodule.dylib

I've tried adding

export DYLD_LIBRARY_PATH=.:$DYLD_LIBRARY_PATH

to the script env, nogo. Any help appreciated.

-Ed

update 4/6/10:

Solved with the info from krunk below. But just copying or ln -s'ing the dylib to a .so name didn't solve it completely. Still wouldn't load. But telling libtool to link the lib with the -module flag created a .so lib that would load. Python version of the lib works now.

Now if I could just get the perl lib working. I'm building swig perl, python, ruby, and lua libs and this fix only got python and lua working.

+3  A: 

Just use *.so as your module extensions in OS X too. I have a vague memory of not being able to load .dylib's and it turning out to be an issue with python itself. . . but I can't find the mailing list post now.

However, rest assured you're following standard practice by using *.so's even on OS X. The only *.dylib's in the entire framework are the libsvn_swig ones.

find /System/Library/Frameworks/Python.framework/Versions/2.6/ -name "*.so"

/System/Library/Frameworks/Python.framework/Versions/2.6//Extras/X11/xcb/xcb.0.0.0.so
/System/Library/Frameworks/Python.framework/Versions/2.6//Extras/X11/xcb/xcb.0.so
/System/Library/Frameworks/Python.framework/Versions/2.6//Extras/X11/xcb/xcb.so
/System/Library/Frameworks/Python.framework/Versions/2.6//Extras/lib/python/CoreGraphics/_CoreGraphics.so
/System/Library/Frameworks/Python.framework/Versions/2.6//Extras/lib/python/OpenSSL/SSL.so
/System/Library/Frameworks/Python.framework/Versions/2.6//Extras/lib/python/OpenSSL/crypto.so
/System/Library/Frameworks/Python.framework/Versions/2.6//Extras/lib/python/OpenSSL/rand.so
/System/Library/Frameworks/Python.framework/Versions/2.6//Extras/lib/python/PyObjC/AppKit/_appmain.so
/System/Library/Frameworks/Python.framework/Versions/2.6//Extras/lib/python/PyObjC/AppKit/_carbon.so
/System/Library/Frameworks/Python.framework/Versions/2.6//Extras/lib/python/PyObjC/AppKit/_inlines.so
/System/Library/Frameworks/Python.framework/Versions/2.6//Extras/lib/python/PyObjC/AppKit/_nsbezierpath.so
/System/Library/Frameworks/Python.framework/Versions/2.6//Extras/lib/python/PyObjC/AppKit/_nsbitmap.so
/System/Library/Frameworks/Python.framework/Versions/2.6//Extras/lib/python/PyObjC/AppKit/_nsfont.so
 /System/Library/Frameworks/Python.framework/Versions/2.6//Extras/lib/python/PyObjC/AppKit/_nsquickdrawview.so
/System/Library/Frameworks/Python.framework/Versions/2.6//Extras/lib/python/PyObjC/AppKit/_nsview.so
/System/Library/Frameworks/Python.framework/Versions/2.6//Extras/lib/python/PyObjC/AppKit/_nswindow.so
/System/Library/Frameworks/Python.framework/Versions/2.6//Extras/lib/python/PyObjC/CFNetwork/_manual.so
jkyle
thanks! your answer got me out of this ditch, got me far down the road in the right direction.
navicore
Just as a preventative, never use static libs in OS X. They're "deprecated" and OSX will _always_ link dynamic libraries over static ones when possible even if you specifically link to a static library.e.g. if you link to /path/to/libfoo.a and libfoo.dylib or libfoo.so exists anywhere in the path, the linker will glibly ignore your request leading to some very interesting runtime undefined symbol errors if the two have different tables.
jkyle