Se fosse per qualsiasi altra libreria, ma glibc ... Suppongo che non ci possano essere modi rapidi, perché glibc è il luogo in cui le cose sono "hard coded". Glibc si adatta alla tua versione del kernel e il suo caricatore è l'istanza che fa effettivamente la cosa giusta (TM) con LD_LIBRARY_PATH.
Forse il modo corretto è:
LD_LIBRARY_PATH="/opt/myglibc/;..." /opt/myglibc/ld-linux.so.2 the_program`
Non sono sicuro che funzioni.
Ad ogni modo, penso che usare un glibc alternativo richieda ancora un framework per implementare, perché i percorsi di ricerca sono cablati a volte e il glibc deve sempre adattarsi al proprio sistema operativo / kernel, quindi non possono esserci binari generici, IMO. Il multiarch di Debian mostra che non è banale, ma può ancora essere fatto. Se uno avesse altri mezzi di discernimento delle librerie oltre all'architettura di destinazione.
Il sito Web mi ha appena dato questo altro thread correlato:
Lì, la risposta accettata include un collegamento a un programma chiamato rtldi , che sembra risolvere il problema glibc. È del 2004, quindi potrebbe non funzionare più dal linker, ma forse vale la pena esaminarlo. La sua fonte è GPLv2.
Geova, Geova
Una volta un mio amico ha avuto l'idea che l'uso effettivo delle librerie condivise è sopravvalutato. E ha un punto: le librerie condivise sono buone per non riempire la memoria del tuo computer con duplicati, ma considerando l'istanza della singola applicazione si tratta solo di pochi MB.
Ci sono solo alcune applicazioni in cui ricorreremo ad azioni come fornire loro il proprio glibc. Salvandoci una lunga analisi, chiamiamole "applicazioni immediate", che sono utili da sole, nel senso di portare a termine il lavoro. Ad esempio browser Web, agenti di posta elettronica, tute da ufficio e lettori musicali consentono all'utente di ottenere ciò che desiderano e ci sono solo poche istanze per utente. Per ritrarre l'altro lato, i servizi di sistema, i gestori delle finestre e persino interi ambienti desktop sono tutti molto importanti, ma semplicemente supportano e spesso non sufficientemente insoliti o critici, in modo che le persone siano disposte a dare loro il proprio glibc.
Il numero di "applicazioni immediate" è piuttosto piccolo, assolutamente per utente e relativamente rispetto a ciò che i sistemi operativi e le DE "di base" generano in questi giorni. Se le applicazioni immediate, come Chrome e Firefox, fossero compilate staticamente, il requisito di memoria aggiuntivo per il sistema medio sarebbe di qualche 100 MB. Un argomento che non va molto lontano sui molti sistemi GB attuali, quindi il collegamento statico per applicazioni immediate può essere un'opzione.
Ci sono anche concetti di spazio di swap e SSD che consentono uno swapin / -out ridicolmente veloce, che aiuta anche a gestire il maggiore fabbisogno di memoria.
Il problema glibc discusso qui non è realmente risolto attraverso il collegamento statico, ma per applicazioni come il browser Web è concepibile una sorta di formato di distribuzione autonomo, in cui il protocollo X, alcuni demoni audio e alcuni metodi del kernel come unica interfaccia. Il vantaggio sarebbe un minor numero di incompatibilità della versione della libreria.
du -h /lib), tieni presente che se quelli fossero compilati staticamente, quella quantità di RAM sarebbe richiesta per ogni e ogni applicazione compilata con loro. Quindi se, ad es. hai due app che usano lo stesso stack di librerie, ora avrai bisogno del doppio della memoria. Tre app? Tre volte tanto. Per non parlare del fatto che negherebbe in gran parte i benefici della memorizzazione nella cache ...