2010-03-21 6 views
7

Intentando cargar una lib compartida del actual '.' dir en una prueba unitaria en osx.cómo hacer que python cargue dylib en osx

Lo que funciona en Linux y NetBSD no es un enlace simbólico _mymodule.so --> ../.libs/libmymodule.so

pero en OSX, pitón de import mymodule no encontrará

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

He intentado añadir

export DYLD_LIBRARY_PATH=.:$DYLD_LIBRARY_PATH 

a la guión env, nogo. Cualquier ayuda apreciada.

-Ed actualización

4/6/10:

resuelto con la información de krunk a continuación. Pero solo copiar o ls -s'ing the dylib a .so name no lo resolvió completamente. Todavía no se carga. Pero al decirle a libtool que vincule la lib con el indicador -module se creó una .so lib que se cargaría. La versión Python de la lib funciona ahora.

Ahora si pudiera hacer funcionar la lib de perl. Estoy compilando swig perl, python, ruby ​​y lua libs y esta solución solo funcionaba con python y lua.

Respuesta

12

Simplemente use * .so como las extensiones de su módulo en OS X también. Tengo un vago recuerdo de no poder cargar .dylib y resulta ser un problema con Python. . . pero no puedo encontrar la publicación de la lista de correo ahora.

Sin embargo, puede estar seguro de que sigue la práctica estándar al usar * .so incluso en OS X. Los únicos * .dylib en todo el marco son los libsvn_swig.

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 
+0

gracias! tu respuesta me sacó de esta zanja, me llevó muy lejos en la dirección correcta. – navicore

+2

Solo como medida preventiva, nunca utilice bibliotecas estáticas en OS X. Están "en desuso" y OSX siempre_ enlazará bibliotecas dinámicas sobre estáticas cuando sea posible, incluso si usted específicamente vincula a una biblioteca estática. p. si enlaza a /path/to/libfoo.a y libfoo.dylib o libfoo.so existe en cualquier parte de la ruta, el vinculador ignorará su solicitud, lo que generará algunos errores de símbolos indefinidos en el tiempo de ejecución muy interesantes si los dos tienen tablas diferentes. – jkyle

Cuestiones relacionadas