Perché i sistemi Unix / Linux non attraversano le directory fino a quando non trovano la versione richiesta di una libreria collegata?

Ho un eseguibile binario chiamato "alpha" che richiede una libreria collegata (libz.so.1.2.7) che si trova in /home/username/myproduct/lib/libz.so.1.2.7

Esporto lo stesso nella mia istanza di terminale prima di generare il mio eseguibile binario eseguendo il comando seguente.

export LD_LIBRARY_PATH=/home/username/myproduct/lib/:$LD_LIBRARY_PATH

Ora, quando ho generato un'altra applicazione "bravo" che richiede la stessa libreria ma di versione diversa, ovvero (libz.so.1.2.8) che è disponibile in /lib/x86_64-linux-gnu/libz.so.1.2.8, il sistema genera il seguente errore.

version `ZLIB_1.2.3.3' not found (required by /usr/lib/x86_64-linux-gnu/libxml2.so.2)

Se deseleziono LD_LIBRARY_PATH, "bravo" si avvia bene. Comprendo che il comportamento sopra riportato è dovuto al fatto che LD_LIBRARY_PATHha la precedenza sui percorsi di directory definiti /etc/ld.so.confdurante la ricerca di librerie collegate e di conseguenza si è verificato l'errore sopra riportato. Sono solo curioso di sapere perché gli sviluppatori di UNIX / LINUX non hanno progettato il sistema operativo per cercare librerie collegate in altre directory secondo la gerarchia se la prima istanza di libreria è di versione diversa.

In poche parole, i sistemi UNIX / LINUX attraversano una serie di directory fino a trovare la libreria richiesta. Ma perché non fa lo stesso fino a quando non trova la versione prevista anziché accettare la prima istanza della libreria indipendentemente dalla sua versione?

— daedalus_hamlet
fonte

Non ne sono del tutto sicuro, ma immagino per la sicurezza. Personalmente preferirei non dovermi preoccupare di un collegamento simbolico da nessuna parte sui miei computer

— Joe

@Joe Molte biblioteche stesse hanno link simbolici che puntano verso di loro. libz.so.1è un collegamento simbolico alibz.so.1.2.8

— Nasir Riley il

Ma perché non fa lo stesso fino a quando non trova la versione prevista anziché accettare la prima istanza della libreria indipendentemente dalla sua versione?

Lo fa, per quanto ne sia consapevole. zlib.so.1.2.7ed zlib.so.1.2.8entrambi hanno un soname di zlib.so.1, quindi tuo alphae bravobinari dicono di aver bisogno zlib.so.1. Il caricatore dinamico carica la prima libreria corrispondente trovata; non sa che la versione 1.2.8 fornisce simboli aggiuntivi di cui ha bravobisogno. (Questo è il motivo per cui le distribuzioni si impegnano a specificare ulteriori informazioni sulla dipendenza, come zlib1g (>= 1.2.8)for bravo.)

Potresti pensare che questo dovrebbe essere facile da risolvere, ma non lo è, anche perché i binari e le librerie elencano i simboli di cui hanno bisogno separatamente dalle librerie di cui hanno bisogno, quindi il caricatore non può verificare che una determinata libreria fornisca tutti i simboli che ne sono necessari. I simboli possono essere forniti in vari modi e l'introduzione di un collegamento tra i simboli e le librerie che li forniscono potrebbe rompere i binari esistenti. C'è anche il divertimento aggiuntivo dell'interposizione dei simboli per complicare le cose (e fare in modo che gli sviluppatori sensibili alla sicurezza si strappino i capelli).

Alcune librerie forniscono informazioni sulla versione che finiscono per essere archiviate .gnu.version_r, con un link alla libreria che fornisce, che sarebbe di aiuto qui, ma libznon è una di queste.

(Dato il nome, mi aspetto che il tuo alphabinario funzioni bene zlib.so.1.2.8.)

— Stephen Kitt
fonte

E si dovrebbe anche notare che il versioning della libreria in stile GNU è diverso dal versioning semantico (-ish) con cui siamo più abituati. Poiché hanno lo stesso numero "corrente", 1, zlib.so.1.2.8 non dovrebbe fornire alcuna funzionalità che zlib.so.1.2.7 non ha, quindi non dovrebbe importare (dal punto di vista ABI) quale sia trovato. Che sia importante dovrebbe essere considerato un difetto.

— John Bollinger,

@Giovanni no, l'unica garanzia è che le librerie con lo stesso soname sono retrocompatibili; le librerie più recenti possono aggiungere funzionalità, non possono rimuoverle o modificarle in modo incompatibile con le versioni precedenti. Vale a dire, un binario creato su zlib 1.2.7 funzionerà con quello o qualsiasi zlib 1 più recente; ma un binario creato contro zlib 1.2.8 non funzionerà necessariamente con un vecchio zlib 1. (E il versioning semantico lo consente; ma la gestione del soname non è il versioning semantico.)

— Stephen Kitt

Sto parlando specificamente delle convenzioni GNU, come ho detto, e immagino in particolare di libtool . Non tutti i progetti seguono questa convenzione, quindi forse è troppo forte per chiamare zlib imperfetto, ma d'altra parte, anche un'interpretazione semantica delle versioni delle biblioteche coinvolte giungerebbe alla stessa conclusione. La compatibilità in avanti (binaria) in questi casi non è una promessa inerente al soname, ma in questo caso è una ragionevole aspettativa.

— John Bollinger,

Sì, capisco bene la relazione tra i numeri CRA e SOVERSION, che ritorna al mio punto originale: la situazione descritta dall'OP sembra essere incompatibile con il corretto utilizzo dello schema CRA . Evitare problemi come i PO è uno degli obiettivi chiave di tale regime. Se zlib aggiunge una nuova (versione di a) interfaccia binaria, il suo numero C dovrebbe essere aumentato. Che un tale bernoccolo possa portare anche a un bernoccolo di sovversione è secondario.

— John Bollinger,

@Giovanni, sospetto che siamo in un accordo violento e che ho frainteso il punto che stavi sollevando. zlibnon usa libtoolcomunque, tranne su Darwin dove si trova ar;-).

— Stephen Kitt,