Installare una libreria localmente nella home directory, ma il programma non la riconosce

10

Sto installando un programma su un server come utente non root. In particolare è tmux 1.5, ma questo dovrebbe applicarsi ampiamente a tutti i programmi installati localmente secondo me (cito il nome del programma nel caso in cui questo problema finisca per non essere il mio errore).

Il programma richiede l'installazione di alcune librerie dipendenti (ad esempio libevent e ncurses). Quindi, li ho installati entrambi localmente poiché non ho accesso come root

cd $HOME/library/installation/folder
DIR=$HOME/local
./configure --prefix=$DIR 
#... make ... make install

Ora, per installare il programma, ho dovuto includere anche i pacchetti della libreria:

cd $HOME/program/installation/folder
./configure --prefix=$DIR CFLAGS="-I$DIR/include" LDFLAGS="-L$DIR/lib"
#... make ... make install

Ok, quindi questo installa il programma senza problemi in $ HOME / local / bin, ma se eseguo il file eseguibile: $ HOME / local / bin / tmux, ottengo il seguente errore:

tmux: errore durante il caricamento delle librerie condivise: libevent-2.0.so.5: impossibile aprire il file oggetto condiviso: nessun file o directory

Mi sembra che il programma non riesca a trovare le librerie desiderate, ma il file libevent-2.0.so.5 esiste effettivamente in $ HOME / local / lib come specificato nelle opzioni di configurazione. Mi chiedo come posso fare in modo che il programma riconosca la libreria installata per poter funzionare. Ho provato a mettere collegamenti simbolici in $ HOME / lib, $ HOME / bin e $ HOME / local / bin, ma nessuno di questi ha funzionato. Qualsiasi idea e suggerimento sarebbe molto apprezzata

— scicalculator
fonte

Presumo -R $DIR/libdi CFLAGSsi, mentre la costruzione tmux(e non libevent). Questo non mi ha aiutato - c'è stato un errore finale da parte di gcc nel dire che non è in grado di riconoscere -R(inoltre, ho provato senza lo spazio tra -Re $DIR). ./configure --disable-shared Funzionava, aggiornando LD_LIBRARY_PATHanche. Ho finito per fare di libeventnuovo con l' --disable-sharedopzione sopra .

20

Prova a ricostruire libevent usando

./configure --disable-shared

Sospetto che questo risolverà il tuo problema perché la libreria sarà collegata durante la creazione del binario e non dovrà essere cercata in fase di esecuzione.

In alternativa, se hai bisogno di un libevent collegato dinamicamente, puoi aggiungere la directory contenente libevent-2.0.so.5 alla variabile di ambiente LD_LIBRARY_PATH:

export LD_LIBRARY_PATH=${HOME}/local/lib/:${LD_LIBRARY_PATH}

— drootang
fonte

Wow, grazie mille per la rapida risposta. Ho finito per usare LD_LIBRARY_PATH per risolvere il problema poiché potevo semplicemente applicare questa correzione a qualsiasi installazione futura della libreria e usare sempre la directory $ HOME / local. Apprezzo l'aiuto!

— scicalculator

7

È inoltre possibile impostare RPATH, che codifica la patch di ricerca della libreria nel file binario stesso .

Aggiungi -R $DIR/liba CFLAGS.

— Cerotti
fonte

2

Nessuna fortuna con gli altri, ma questo ha funzionato per me, da qui :

sudo ln -s /usr/local/lib/libevent-2.0.so.5 /usr/lib64/libevent-2.0.so.5

— beardc
fonte

2

Ho fatto una domanda simile , abbastanza interessante anche sulla costruzione tmuxdi tutte le cose (anche se sono ancora sicuro che ciò riguardi praticamente qualsiasi situazione in cui GNU configuree makesono usati insieme.

Credo che un approccio più pulito sia quello di utilizzare il cosiddetto "rpath", il percorso di ricerca della libreria incorporato nel binario. Il -rpathpassaggio almeno del linker GNU ldspecifica il percorso.

La riga di comando di compilazione apparirà quindi come segue:

PKG_CONFIG_PATH=/path/to/libevent/lib/pkg-config LDFLAGS=-Wl,-rpath,/path/to/libevent/lib ./configure ...

Non è davvero fondamentale qui, ma PKG_CONFIG_PATHsopra è semplicemente il modo consigliato per fare ciò che le persone altrimenti ottengono manualmente inviando -L/path/to/libevent/lib -I/path/to/libevent/includeallo ./configurescript. Quando si crea libevent, installa i propri file di configurazione per pkg-config(che viene utilizzato da ./configure). Dovresti usarlo, perché libevent sicuramente sa quali switch dovrebbero essere usati quando lo costruisci contro di esso.

Comunque, in alcune situazioni, -rpathè un approccio più pulito per risolvere il problema.

LD_LIBRARY_PATHsoluzioni basate su, tuttavia, ti consentono di destreggiarti con la libreria utilizzata dal tuo binario integrato in fase di runtime, che a volte è desiderabile. Ma se vuoi solo costruire contro una libreria particolare che hai messo in un posto dedicato nella tua cartella home da qualche parte, penso che le -rpathsoluzioni basate su basi debbano essere considerate una risposta canonica.

La cosa strana è il motivo tmuxper cui gli script di compilazione non deducono questo percorso dal percorso di ricerca della libreria durante la costruzione. Forse non hanno bisogno e non dovrebbero, non lo so. È una coincidenza che sia successo a noi che costruiamo tmux?

— AMN
fonte