2012-09-13 10 views
9

Possiedo un eseguibile che carica implicitamente diverse librerie .so, tutte costruite da me. Per la distribuzione, o almeno testing/debugging, mi piacerebbe averli tutti nella stessa directory:Come codificare la posizione dell'eseguibile in un percorso Linux?

my_executable 
libmylib1.so 
libmylib2.so 

Per ottenere l'eseguibile per caricare le librerie implicitamente, mi piacerebbe impostare un rPath (DT_RUNPATH) per la directory dell'eseguibile. Con OS X, farei questo modo:

clang -dynamiclib -o libmylib1.dylib -install_name @rpath/libmylib1.dylib src1.c src2.c  
clang -dynamiclib -o libmylib2.dylib -install_name @rpath/libmylib2.dylib src3.c src4.c 
clang -o my_executable -L. -llibmylib1.so -llibmylib2.so -Wl,-rpath,@loader_path/. main.c 

Avviso del @loader_path/. che forma rpath dell'eseguibile in OS X. Con Linux, il più vicino che può venire a questo è

gcc -dynamiclib -o libmylib1.so src1.c src2.c  
gcc -dynamiclib -o libmylib2.so src3.c src4.c 
gcc -o my_executable -L. -llibmylib1.so -llibmylib2.so -Wl,-rpath=. main.c 

Il il problema qui è che su Linux il percorso segue la directory di lavoro corrente, non la directory dell'eseguibile. C'è un modo per realizzare la stessa cosa su Linux?

risposta

6

È necessario utilizzare la stringa letterale $ORIGIN come runpath, ovvero la posizione dell'eseguibile dal caricatore dinamico.

+0

E 'stato! Grazie. –

2

Una soluzione comune è creare un wrapper di shell shell che determini in quale directory si trova l'eseguibile e imposta correttamente LD_LIBRARY_PATH prima di eseguire l'eseguibile effettivo.

+3

Una soluzione comune ma sporca, le persone dovrebbero conoscere il percorso – wich