non è propriamente così.
Per motivi che dovrebbero essere evidenti normalmente si vuole evitare che ciò accada, ma non è affatto impossibile "far convivere" cose diverse, se proprio non se ne può fare a meno.
Ci sono molti modi per farlo. Le variabili di ambiente sono definite e (ri)definibili per il singolo processo; per usare un eseguibile piuttosto che un altro basta ridefinire $PATH (o avviare esplicitamente una dato file con il path completo); per fare una cosa analoga con le librerie dinamiche, il dynamic linker utilizza la variabile di ambiente "LD_LIBRARY_PATH"; esistono inoltre meccanismi potenti (e pericolosi...) quali quello del preload (variabile "LD_PRELOAD"), che consente addirittura di far usare ad un eseguibile una libreria completamente diversa (purché ovviamente "compatibile" a livello di API) da quella per la quale è stato compilato:
Modifying a Dynamic Library Without Changing the Source Code | Linux Journal
A Simple LD_PRELOAD Tutorial - good coders code, great coders reuse
Ad es. (grazie all'esistenza di "libsoxr-lsr") con questo trucco puoi far usare libsoxr a qualsiasi programma che è stato scritto e compilato per utilizzare invece la libsamplerate! (come feci a suo tempo per mpd, quando questo ancora non supportava nativamente libsoxr).
Oppure ancora, nei casi più "estremi", si può addirittura creare una "chroot", cioè mettere "un intero sistema" (solo quel che serve...), con il suo assortimento di librerie e binari vari, "all'interno" di un altro.
Pensa che, al lavoro, per mantenere la compatibilità con del vecchio software "custom" che sarebbe stato troppo laborioso (e materialmente quasi impossibile) "portare" su versioni aggiornate del sistema, in alcune macchine ho una intera (vecchissima) distribuzione Debian con tutto il relativo software che "gira dentro" ad un sistema "up-to-date"!
(e no, non sto parlando di una macchina virtuale, con il relativo overhead: con una chroot in sostanza si hanno più "sistemi" diversi che condividono lo stesso kernel, senza alcun overhead!).
il fatto è che di norma tutte le applicazioni fanno parte del sistema stesso, e sono distribuite con esso!
I problemi nascono quando si vogliono utilizzare applicazioni di terze parti che vogliono fare le cose a modo loro...
di norma semplicemente non succede, proprio perché per una data distribuzione di Linux tanto l'uno quanto l'altro sono compilati con la stessa versione di libAV. Stesso dicasi per tutto il resto. Per questo si chiamano "distribuzioni".
Non di meno, in generale non è affatto impossibile avere versioni diverse di una libreria che convivono tranquillamente (senza bisogno di "trucchi"). Dipende però da come è fatta la libreria in questione (se supporta il versioning), e da come sono fatti i relativi pacchetti.
Rispondi quotando