2010-10-18 13 views
19

Sto lavorando su un plugin per Firefox che utilizza librerie esterne per il rendering di grafica 3D sul browser.come collegarsi alla lib condivisa dalla lib condivisa con il relativo percorso

Il problema è che voglio che il plugin utilizzi librerie esterne con esso senza modificare la variabile LD_LIBRARY_PATH.
Le librerie sono installate in una posizione relativa al plug-in (anche una libreria condivisa), mentre l'eseguibile reale (cioè il browser) può essere posizionato da qualche altra parte.

Alcune cose che devi sapere. sto testando su Ubuntu (nessun problema a versione Windows del plugin) mie dipendenze sono le librerie OpenSceneGraph e la compilazione statica renderà il plugin davvero grande (non un'opzione se c'è un altro uno)

La speranza è possibile help me

Cordiali saluti.

+2

Questo potrebbe essere utile: http://stackoverflow.com/questions/3015411/shipping-gnu-linux-firefox-plugin-with-shared-libraries-per-installation-with-no –

+0

Interessante, posso confermarlo con un semplice programma di test. Usa 'dlopen()' per caricare i collegamenti 'lib1' e' lib1' in un 'lib2' e usa' $ ORIGIN' per caricarlo da un percorso relativo. Funziona senza problemi. –

risposta

0

È possibile utilizzare il flag -L durante la compilazione per specificare il percorso relativo in cui il linker può trovare gli oggetti condivisi.

Se è già stata generata la lib, è possibile effettuare il collegamento invocando direttamente il comando ld.

Suggerimenti: È possibile controllare facilmente se alcuni simboli sono definiti in una lib utilizzando il comando unix nm. Questo è un modo utile per verificare che il collegamento sia ben fatto.

(Se fossi in te, vorrei solo cambiare temporaneamente la LD_LIBRARY_PATH come hai detto nel tuo post. Perché non vuole fare questo?)

+0

Non si tratta del linker che trova le librerie, ma del caricatore che le trova in una posizione relativa alla libreria attualmente caricata (il plugin). Con i plugin non puoi controllare come viene invocato il processo host (cioè il browser), quindi le variabili ambientali non lo faranno. Su OS X '@ loader_path' fa il trucco, su Linux non lo so. –

+0

Ok scusa per la cattiva lettura. Forse la cosa migliore da fare è usare comandi specifici della lingua per caricare la lib in fase di runtime. Probabilmente cancellerò questa risposta domani se non trovo un modo per risolverlo correttamente. – ThR37

+0

Il solito caricamento dinamico ha il maggiore svantaggio di non avere gli stub, quindi devi risolvere i simboli manualmente:/ –

26

Utilizzare l'opzione rpath durante il collegamento e specificare la 'speciale 'percorso $ ORIGIN.

Esempio:

-Wl,-R,'$ORIGIN/../lib' 

Ecco un sito che elabora utilizzando $ ORIGIN: http://www.itee.uq.edu.au/~daniel/using_origin/

+5

il link è rotto (5 anni sì lo so :)) – dashesy

+0

[Wayback Machine] (https: // web.archive.org/web/20130915172134/http://itee.uq.edu.au/~daniel/using_origin/) al salvataggio :) – 865719

+0

Inoltre, [sembra] (https://en.wikipedia.org/wiki/Rpath) che ['chrpath'] (http://man.devl.cz/man/1/chrpath) e [' patchelf'] (http://man.devl.cz/man/1/patchelf) può aiutare anche (non li ho ancora provati però ...) – 865719

-2

E 'sbagliato usare relativa rpath per motivi di sicurezza,

Si dovrebbe usare le funzioni libdl (dlopen, ecc.)

+3

Se implementato male, l'uso di rpath può certamente causare problemi, ma Linux (e altri sistemi) sono dotati di protezioni integrate. Ad esempio, in determinate circostanze, ld.so non espanderà affatto ORIGIN. Inoltre, i percorsi relativi sono assolutamente necessari per i programmi rilocabili; altrimenti, si finisce per dover installare un pacchetto software in una posizione fissa, ad es. essere obbligati a installare matlab su/usr/share/matlab sempre al posto di qualcosa come/opt/matlab, o/usr/local/matlab, ecc. –

+1

Inoltre, le persone possono prendere decisioni informate sull'utilizzo dell'espansione ORIGIN, in particolare se il software in questione è di propria creazione e viene utilizzato sul proprio hardware. –