Configurazione side-by-side su Linux / ELF

1

Una delle migliori / peggiori innovazioni software Microsoft (ideale per la compatibilità, terribile per l'efficienza) è stata la configurazione Side by Side di Windows. Ciò consente, tra le altre cose, che componenti diversi di un programma possano avere più versioni delle librerie di runtime C / C ++ caricate nello stesso processo.

Questo mi ha sempre colpito per l'eccellente compatibilità con le versioni precedenti che offre. Ad esempio, è possibile eseguire un programma antico che si collega a runtime di C / C ++ molto vecchi e collegarlo o iniettare dinamicamente una nuova DLL che dipende da un nuovo runtime di C / C ++ e tutte le istanze separate dei runtime coesisteranno simultaneamente all'interno dello spazio degli indirizzi e saranno chiamati dall'assemblea che li fa riferimento.

Su Linux, tuttavia, i binari per i quali la sorgente non è disponibile tendono a "marcire" nel tempo, piuttosto rapidamente. Il motivo è che i programmi più interessanti alla fine devono collegarsi alle librerie installate nelle directory di sistema ( /usr/lib , ecc.). Ma dal momento che i runtime di C / C ++ e le librerie di sistema cambiano frequentemente ABI, il tuo programma smette di funzionare quando aggiorni la tua distribuzione.

Ciò può anche essere causato, ad esempio, da un software con "backend" che alla fine si collega alle tue librerie di sistema. Un esempio è OpenGL, che a causa della varietà e della volatilità delle implementazioni, non può essere fornito dalle distribuzioni binarie. Devono semplicemente dipendere dall'implementazione OpenGL del sistema.

Ma se i tuoi link OpenGL di sistema contro libstdc++ , potresti potenzialmente essere morto nell'acqua. Quello che succede è che il vecchio eseguibile carica la sua copia locale di libstdc++ , e la libreria condivisa OpenGL carica la copia del sistema di libstdc++ . I due conflitti, e uno di loro si rifiuta di caricare, e di solito questo significa che OpenGL si rifiuta di funzionare e il programma si arresta in modo anomalo.

Per un "semplice" sviluppatore di applicazioni, è qualcosa come WinSxS realizzabile su Linux senza importanti modifiche architetturali al formato binario ELF e al kernel Linux ABI? O è qualcosa che dovrebbe essere incorporato nelle librerie di sistema in fase di compilazione e distribuito per un lungo periodo di tempo apportando modifiche a ELF, glibc, libstdc ++, compilatori e così via?

    
posta allquixotic 13.08.2012 - 19:08
fonte

1 risposta

1

Questo potrebbe essere estraneo agli sviluppatori di Windows, ma la soluzione è fornire l'origine e ricompilare quando l'ABI cambia. Non hai nemmeno bisogno di fornire tutta la fonte, basta compilare un wrapper sulle interfacce che è probabile che cambi, e collegarlo con un binario che contiene le cose proprietarie. Pensa a creare il tuo ABI stabile. Nvidia ha seguito con successo questo modello per sempre. Esistono strumenti come DKMS che aiutano a rendere il processo di ricompilazione essenzialmente invisibile all'utente.

Se il tuo prodotto è abbastanza popolare, la community ti aiuterà anche a mantenere il wrapper quando l'API cambia. Ad esempio, ho eseguito patch community per il driver di Nvidia prima che venissero rilasciati gli aggiornamenti ufficiali per il kernel 2.6.

Non è facile come avere i propri file di libreria per tutto, ma poi, per la maggior parte delle applicazioni, è così semplice. La soluzione wrapper è necessaria solo per un sottoinsieme di software di livello abbastanza basso.

    
risposta data 13.08.2012 - 22:11
fonte