2009-12-20 5 views
18

stanno collegando un (estensione Python) libreria che incorpora il motore di Matlab con il seguente comando (generato usando cmake)Collegamento a una libreria dinamica su un Mac con il percorso completo

c++ -mmacosx-version-min=10.6 -bundle -headerpad_max_install_names -o library.so library.o /Applications/MATLAB_R2009b.app/bin/maci64/libeng.dylib /Applications/MATLAB_R2009b.app/bin/maci64/libmx.dylib -framework Python 

conseguente

$ otool -L library.so 
library.so: 
    @loader_path/libeng.dylib (compatibility version 0.0.0, current version 0.0.0) 
    @loader_path/libmx.dylib (compatibility version 0.0.0, current version 0.0.0) 
    /System/Library/Frameworks/Python.framework/Versions/2.6/Python (compatibility version 2.6.0, current version 2.6.1) 
    /opt/local/lib/gcc44/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.13.0) 
    /opt/local/lib/gcc44/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) 
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.0.0) 

Tuttavia, quando si tenta di utilizzare la libreria, ottengo un messaggio di errore:

ImportError: dlopen(./library.so, 2): Library not loaded: @loader_path/libmex.dylib 
    Referenced from: ./library.so 
    Reason: image not found 

credo il problema deriva dal fatto che il linker include i file matlab dylib nel formato @loader_path/libeng.dylib anziché utilizzare il percorso completo, anche se fornisco il percorso completo a g++. Come posso forzare il linker a utilizzare il percorso completo?

so una soluzione è quella di utilizzare

export DYLD_LIBRARY_PATH=/Applications/MATLAB_R2009b.app/bin/maci64:$DYLD_LIBRARY_PATH 

che è dove i file di libreria risiedono, ma mi piacerebbe evitare che in quanto causa di alcuni altri problemi.

+0

prega di fare riferimento la mia risposta a questo link [Add_libray] [1] [1]: http://stackoverflow.com/questions/4876740/xcode-keeps-searching-dylib-at-wrong- path/19245310 # 19245310 – itechnician

risposta

29

modificando manualmente i file utilizzando install_name_tool

install_name_tool -change "@loader_path/libeng.dylib" "/Applications/MATLAB_R2009b.app/bin/maci64/libeng.dylib" library.so 
install_name_tool -change "@loader_path/libmx.dylib" "/Applications/MATLAB_R2009b.app/bin/maci64/libmx.dylib" library.so 

potrei usare questo come una soluzione temporanea, ma mi chiedo se non c'è una soluzione migliore dove al linker viene fornita un'impostazione per utilizzare i percorsi completi.

+2

questo è utile, ma hai ragione, ci dovrebbe essere un modo per farlo in CMake – eqzx

+0

Ho finito per dover eseguire l'operazione inversa; sostituendo un percorso assoluto con uno che coinvolge '@ loader_path'. La [pagina man dyld] (https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/dyld.1.html) è stata utile per spiegare il comportamento di dyld per quanto riguarda i percorsi assoluti e l'espansione di '@ loader_path'. – nornagon

5

Esaminare l'opzione -rpath al comando ld per controllarlo. Potresti anche essere interessato ai contenuti di https://github.com/bimargulies/jni-origin-testbed, che è una dimostrazione di alcune tecnologie rilevanti.

La tecnica fondamentale qui è:

install_name_tool -change libsl2.so "@loader_path/libsl2.so" libsl1.so 
+1

Potresti approfondire un po 'questo argomento? Sto avendo lo stesso problema. Mi sento come se alcuni dei percorsi del mio progetto non guardassero nel posto giusto! – Yasin

-2

È anche possibile utilizzare il collegamento simbolico!

+1

hai letto altre risposte e capito il problema? –

6

Si noti che alcuni dei problemi con DYLD_LIBRARY_PATH possono essere evitati utilizzando invece DYLD_FALLBACK_LIBRARY_PATH. Questo sarà usato solo se la lib non può essere trovata nei percorsi predefiniti.

+0

Usando questo appena rotto il guscio mi trovavo, e mi ha dato: '' ' python dyld: Libreria non caricato: @loader_path /../ lib/libpython2.7.dylib di riferimento da: .../bin/python Motivo: immagine non trovata Trappola Trace/BPT: 5 '' ' –