Per cosa è usato ld_library_path?
In primo luogo le variabili di ambiente sono state sviluppate per UNIX ma ora Windows e Linux hanno anche queste variabili. Quando viene creato un processo, eredita una copia dell'ambiente di runtime del suo genitore, ad eccezione delle modifiche esplicite apportate dal genitore quando il figlio viene creato per impostazione predefinita. Una coppia Nome/Value costituisce una variabile di ambiente e qualsiasi numero di essi può essere generato e referenziato in qualsiasi momento. Le lettere comunemente maiuscole vengono utilizzate durante la denominazione delle variabili di ambiente. Questo aiuta a differenziare le variabili di ambiente da altri tipi di nomi nel codice di programmazione in generale.Nel sistema operativo UNIX, le variabili di ambiente sono sensibili al caso, ma non su DOS, OS/2 o Windows.
LD_Library è anche una variabile ambientale del sistema operativo UNIX/Linux; In questo articolo discuteremo in dettaglio questa variabile di ambiente.
Utilizzo della variabile LD_Library_Path
Nel sistema Unix/Linux Ld_library_path Per raccontare Dynamic Link Loader, un piccolo programma che inizia tutte le tue applicazioni, per determinare dove cercare librerie dinamiche condivise con cui un'applicazione è stata collegata. Un colon (:) separa un elenco di directory e questo elenco viene controllato anche prima del percorso/percorsi di ricerca integrati e posizioni convenzionali come (/lib,/usr/lib ...).
Alcuni altri usi di LD_Library_Path sono:
- Confronto di nuove versioni di una libreria condivisa con un'applicazione che è stata precedentemente compilata.
- Trasferimento di librerie condivise, ad esempio, per mantenere vive le versioni precedenti.
- Viene inoltre utilizzato per creare un sistema autosufficiente, trasferibile per applicazioni più grandi in modo che siano indipendenti dal cambiamento delle librerie di sistema.
Problema con LD_Library_Path
È molto utile fino a quando non provi a usarlo per risolvere i tuoi problemi. Questa linea sembra strana, ma questo è ciò che accade davvero quando si tenta di applicarla in un ambiente utente/sistema, lo scenario peggiora e tutte le variabili ambientali iniziano a seconda e si blocca in quanto non può gestire tutte le attività!
Alcuni problemi affrontati usando LD_Library_Path sono:
Sicurezza: Le directory LD_Library_Path vengono controllate prima, prima della loro posizione effettiva. Questo approccio potrebbe essere utilizzato da un individuo dannoso per costringere la tua applicazione a eseguire una versione dannosa di una libreria condivisa. Uno dei motivi per cui i eseguibili setuid/setGid ignorano quella variabile è a causa di questo.
Prestazione: Link Loader deve guardare in tutte le directory fornite fino a quando non trova librerie condivise (collegate all'applicazione). Di conseguenza, causerà l'apertura di diverse chiamate di sistema e farle arresti alla crash con Enoent "Nessun file o directory". Se il percorso specificato ha molte directory, ci vorrà molto tempo e puoi verificarlo dal tempo di avvio dell'applicazione. Di conseguenza questo farà rallentare l'intero sistema.
Incoerenza: Il problema più diffuso causato dall'uso di LD_Library_Path è incoerenza. LD_Library_Path obbliga un programma per caricare una libreria condivisa rispetto alla quale non era collegata, il che è sicuramente incompatibile con la versione originale. Questo può essere molto evidente, ad esempio quando l'applicazione si arresta in modo anomalo, oppure può causare risultati errati se la libreria raccolta non corrisponde esattamente alla funzionalità della versione originale. Questo sarà difficile debug di quest'ultimo, soprattutto.
Soluzione
La soluzione migliore è il meno lo usi, meno guai dovrai affrontare. Infatti cerca di evitare l'uso di ld_library_path:
Come evitare ld_library_path:
Fornire la posizione corretta della libreria condivisa: Quando si compila l'applicazione, è necessario fornire la posizione esatta delle librerie condivise e specificare il percorso nell'opzione Linker "-Rpath" per informare il linker per includerli al RunPath del tuo eseguibile o è possibile utilizzare la variabile LD_RUN_PATH per specificare più percorsi
Strumento per risolvere il problema:Per correggere/modificare l'esecutabile RunPath di un eseguibile binario, sono disponibili programmi, come ChrPath sotto Linux. Il problema in questo modo è che lo spazio eseguibile che porta queste informazioni (i.e. la stringa del percorso) non può essere ampliata, i.e. Puoi riscrivere solo un percorso esistente.
Non mettere LD_Library_Path nel profilo utente: Mettendo LD_Library_Path nel profilo utente creerai problemi per te stesso, quindi evitalo.
Non mettere LD_Library_Path nel profilo di sistema: Alcuni ISV forniscono software che inseriscono automaticamente le impostazioni del percorso della libreria LD globali nei profili di sistema durante l'installazione o persino spingono l'utente a farlo. Dì semplicemente di no! Prova a gestire il problema in un altro modo, ad esempio scrivendo uno script wrapper o dì al fornitore di rettificarlo.
LD_Library_Path è utile se utilizzato per tre usi menzionati nella porzione di utilizzo ma cerca di usarlo il meno possibile per proteggerti dall'entrare nei guai.
Conclusione
Ld_library_path è una variabile ambientale utilizzata nei sistemi Linux/Unix. Viene utilizzato per raccontare caricanti di collegamenti dinamici dove cercare librerie condivise per applicazioni specifiche. È utile finché non ti scherzi. È meglio evitare l'uso di ld_library_path e utilizzare alternative. In questo articolo viene discusso l'uso della variabile ambientale LD_Library_Path e quindi viene discusso il problema con l'uso di essa e quindi la sua soluzione. Dopo aver letto questo articolo, conoscerai i pro e i contro della variabile LD_Library_Path.