2010-03-21 8 views
7

Próbujesz załadować udostępnione lib z bieżącego "." dir w teście jednostkowym na osx.jak sprawić, aby Python załadował dylib na osx

Co działa na Linux i NetBSD jest dowiązaniem _mymodule.so --> ../.libs/libmymodule.so

ale na OSX, Pythona import mymodule nie znajdzie

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

Próbowałem dodanie

export DYLD_LIBRARY_PATH=.:$DYLD_LIBRARY_PATH 

do skrypt env, nogo. Każda pomoc doceniona.

-Ed

Aktualizacja 06.04.10:

rozwiązany z informacji od Krunk poniżej. Ale kopiowanie lub ln-s'ing dylib do nazwy .so nie rozwiązało go całkowicie. Nadal nie ładował się. Ale mówienie libtoolowi o połączeniu lib z flagą -module stworzyło bibliotekę .so, która by się wczytała. Wersja Pythona z biblioteki działa teraz.

Teraz, gdybym tylko mógł uruchomić działanie biblioteki perl. Buduję pliki perl, python, ruby ​​i lua libs, a ta poprawka działa tylko z Pythonem i Lua.

Odpowiedz

12

Po prostu użyj * .so jako rozszerzenia modułów również w OS X. Mam niejasne wspomnienie, że nie można załadować pliku .dylib i okazuje się, że jest to problem z pytonem. . . ale nie mogę teraz znaleźć wpisu na liście mailingowej.

Zapewniamy jednak, że stosujemy standardową praktykę, używając * .so nawet w systemie OS X. Jedynymi * .dylibami w całym systemie są biblioteki 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

dziękuję! Twoja odpowiedź wyciągnęła mnie z tego rowu, poprowadziła mnie daleko w dobrą stronę. – navicore

+2

Tak jak zapobiegawczo, nigdy nie używaj statycznych bibliotek w systemie OS X. Są one "przestarzałe", a system OSX zawsze łączyć biblioteki dynamiczne ze statycznymi, jeśli to możliwe, nawet jeśli łączysz się ze statyczną biblioteką. np. jeśli podasz link do /path/to/libfoo.a i libfoo.dylib lub libfoo.so istnieje gdziekolwiek w ścieżce, linker zignoruje twoją prośbę prowadzącą do bardzo interesujących błędów niezdefiniowanego symbolu wykonania, jeśli te dwie mają różne tabele. – jkyle

Powiązane problemy