2010-03-20 27 views
10

Sto creando un'applicazione C++ che utilizza la libreria Intel IPP. Questa libreria è installata per impostazione predefinita in/opt e richiede di impostare LD_LIBRARY_PATH sia per la compilazione che per l'esecuzione del software (se si sceglie il collegamento alla libreria condivisa, cosa che ho fatto). Ho già modificato il mio configure.ac/Makefile.am in modo che non sia necessario impostare tale variabile durante la compilazione, ma non riesco ancora a trovare la libreria condivisa in fase di esecuzione; Come lo faccio?Come faccio a sbarazzarmi di LD_LIBRARY_PATH in fase di esecuzione?

Sto compilando con la bandiera -Wl, -R/path/to/libdir utilizzando g++

Update 1: In realtà il mio programma binario ha alcune librerie IPP correttamente collegati, ma solo uno non è:

$ ldd myprogram 
linux-vdso.so.1 => (0x00007fffa93ff000) 
libippacem64t.so.6.0 => /opt/intel/ipp/6.0.2.076/em64t/sharedlib/libippacem64t.so.6.0 (0x00007f22c2fa3000) 
libippsem64t.so.6.0 => /opt/intel/ipp/6.0.2.076/em64t/sharedlib/libippsem64t.so.6.0 (0x00007f22c2d20000) 
libippcoreem64t.so.6.0 => /opt/intel/ipp/6.0.2.076/em64t/sharedlib/libippcoreem64t.so.6.0 (0x00007f22c2c14000) 
[...] 
libiomp5.so => not found 
libiomp5.so => not found 
libiomp5.so => not found 

Naturalmente la biblioteca è lì:

$ locate libiomp5.so 
/opt/intel/ipp/6.0.2.076/em64t/sharedlib/libiomp5.so 
+0

Potrei aver bisogno di cambiare la domanda a qualcos'altro, ma ho bisogno di suggerimenti, sono a corto di idee – Kjir

+0

Hm, mi chiedo se sia una coincidenza che a quello manchi anche l'estensione del numero di versione - forse l'IPP non è proprio installarsi giusto? – Cascabel

+2

Mi chiedo se la libreria mancata non fa riferimento al tuo programma, ma piuttosto dalle biblioteche che i tuoi riferimenti? –

risposta

2

Come suggerito da Richard Pennington, la libreria mancante non viene utilizzata direttamente dalla mia applicazione, ma viene utilizzata dalle librerie condivise che utilizzo. Poiché non riesco a ricompilare IPP, la soluzione al mio problema è di aggiungere -liomp5 durante la compilazione, usando l'opzione -R per il linker. Questo in realtà aggiunge il percorso per libiomp5.so che risolve il problema!

-1

bash:

export LD_LIBRARY_PATH=/path/to/lib 

tcsh:

setenv LD_LIBRARY_PATH /path/to/lib 
+0

La domanda è come * non * deve impostare LD_LIBRARY_PATH, non come impostarlo. Questa è una domanda molto ragionevole, poiché l'impostazione di LD_LIBRARY_PATH può essere piuttosto malvagia. – Cascabel

4

Con /path/to/lib vuoi dire percorso della directory che contiene la libreria, o il percorso del file vero e proprio?

L'opzione -R fornita un argomento di directory viene trattata come -rpath da ld, che è l'opzione che si sta effettivamente volendo qui. Aggiunge la directory specificata al percorso di ricerca della libreria di runtime. Questo dovrebbe funzionare, a patto che tu gli dia la directory e non il nome del file. Sono abbastanza fiducioso circa che, dopo aver fatto io, e perché è una delle indicazioni date da libtool:

biblioteche sono stati installati in:

/path/to/library-directory

Se si desidera collegarsi alle librerie installate in una determinata directory, LIBDIR, è necessario utilizzare libtool e specificare il percorso completo della libreria o utilizzare il flag `-LLIBDIR ' durante il collegamento e fare almeno uno dei seguenti:

  • aggiungere LIBDIR al `LD_LIBRARY_PATH 'variabile d'ambiente durante l'esecuzione
  • aggiungere LIBDIR al` LD_RUN_PATH' variabile d'ambiente durante il collegamento
  • utilizzare il `-Wl, -rpath -Wl, LIBDIR' linker bandiera
  • chiedere all'amministratore di sistema di aggiungere LIBDIR a `/etc/ld.so.conf'

(ho incolla questo qui dal plausibilmente una delle altre opzioni potrebbe essere più desiderabile - per esempio LD_RUN_PATH è possibile salvare la modifica makefile)

+0

Ho modificato la domanda per specificare meglio che effettivamente punto a una directory. L'aggiunta di questa opzione alla fase di collegamento ha effettivamente risolto il problema in fase di compilazione, ma il tempo di esecuzione continua a non funzionare. Naturalmente ho fatto 'make clean && make' per essere sicuro di aver aggiornato i binari ... – Kjir

+0

Si potrebbe provare il percorso' LD_RUN_PATH', per ogni evenienza? – Cascabel

2

È possibile controllare se il percorso della biblioteca è essere prelevato dal tuo flag -R eseguendo il comando ldd o il comando readelf sul tuo binario. La variabile di ambiente LD_LIBRARY_PATH è un override, quindi non dovrebbe essere necessaria normalmente.

-1

Prova a configurare il tuo ldconfig tramite ld.so.conf in modo che cerchi la directory /opt/... per impostazione predefinita.

+2

Questa non è un'opzione valida, sarebbe come impostare LD_LIBRARY_PATH, ma probabilmente meno portabile. Inoltre richiederebbe un compito amministrativo, che non risolva il problema principale, che è quello di rendere il più semplice possibile per il prossimo utente/sviluppatore di eseguire il software. – Kjir

0

È consigliabile utilizzare l'opzione -R, se possibile.

In caso contrario, rinominare il file eseguibile e creare uno script di avvio che esegua il file eseguibile e, in questo caso, impostare LD_LIBRARY_PATH solo per tale ambito.

A seconda della piattaforma, è possibile modificare ld.so.conf tramite /etc/ld.so.conf.d (Redhat/Fedora viene in mente) che rende la distribuzione delle modifiche a ld.so "più semplice" da uno scenario di distribuzione .

+0

Hai guardato le informazioni già pubblicate?L'OP * è * usando l'opzione '-R'; il problema è che non funziona come previsto. E la modifica di ld.so.conf è come impostare LD_LIBRARY_PATH, tranne che peggio: si applica a qualsiasi cosa, non solo a questo programma, e la distribuzione in un modo che richiede sempre la root non è più facile. – Cascabel

+0

Inoltre, anche se uno script di wrapper funzionerebbe, non è solo inelegante, ma in alcuni casi improbabili ma possibili, potrebbe essere problematico - se il programma in questione lancia altri programmi, erediteranno quella variabile di ambiente, e sarai di nuovo aprire di nuovo i soliti problemi con LD_LIBRARY_PATH. – Cascabel

+0

Non sto dicendo che siano buone soluzioni, ma se l'utente finale sta installando componenti di runtime che sono delle dipendenze e questi non sono esplicitamente aggiunti ai metodi di ricerca del sistema, allora le opzioni sono estremamente limitate. Ci sono fondamentalmente solo due modi per trovare librerie dinamiche al di fuori dei valori di default - si aggiorna ld.so, oppure si usa LD_LIBRARY_PATH (o LD_RUN_PATH) in qualche modo. – Joe

0

Oltre a tutti i suggerimenti utili pubblicati qui .. non si sta tentando di utilizzare una libreria specifica a 64 bit su un sistema a 32 bit (o viceversa, a seconda delle altre condizioni), vero?

+0

Se fosse così, non funzionerebbe neanche impostando LD_LIBRARY_PATH ... – Kjir

Problemi correlati