Se fosse para qualquer outra biblioteca, mas glibc ...
Eu suponho que não pode haver maneiras rápidas, porque o glibc é o lugar onde as coisas são "codificadas". O glibc se ajusta à sua versão do kernel e seu carregador é a instância que realmente faz a coisa certa (TM) com LD_LIBRARY_PATH .
Talvez a maneira correta seja:
LD_LIBRARY_PATH="/opt/myglibc/;..." /opt/myglibc/ld-linux.so.2 the_program'
Não tenho certeza se isso funciona, no entanto.
De qualquer forma, acho que o uso de um glibc alternativo requer uma estrutura ainda a ser implementada, porque os caminhos de pesquisa são conectados às vezes e o glibc sempre precisa caber em seu OS / kernel, portanto não pode haver binários genéricos, IMO. O multiarch do Debian mostra que não é trivial, mas ainda pode ser feito. Se alguém tivesse outros meios de discernir bibliotecas além da arquitetura de destino.
O site acabou de me dar este outro tópico relacionado:
Lá, a resposta aceita inclui um link para um programa chamado rtldi , que parece resolver o problema da glibc . É de 2004, então pode não funcionar mais do linker, mas talvez valha a pena investigar. Sua fonte é GPLv2.
Jehova, Jehova
Um amigo meu teve a ideia de que o uso real de bibliotecas compartilhadas é superestimado. E ele tem um ponto: bibliotecas compartilhadas são boas para não encher a memória do seu computador com duplicatas, mas considerando a instância do aplicativo individual, isso é apenas alguns MBs.
Existem apenas alguns aplicativos nos quais recorreríamos a ações como fornecer seus próprios glibc. Salvando-nos uma longa análise, vamos chamá-los de "aplicações imediatas", que são de uso próprio, no sentido de fazer o trabalho. Por exemplo, navegadores da web, agentes de usuários de e-mail, roupas de escritório e tocadores de música permitem que o usuário consiga o que eles querem e há apenas algumas instâncias por usuário. Retratar o outro lado, serviços de sistema, gerenciadores de janela, até ambientes de desktop inteiros são todos muito importantes, mas meramente apoiando e frequentemente não são suficientemente incomuns ou críticos, de modo que as pessoas estejam dispostas a dar a eles sua própria glibc.
O número de "aplicações imediatas" é bastante pequeno, absolutamente por usuário e relativamente comparado ao que os sistemas operacionais "básicos" e os DEs geram nos dias de hoje. Se aplicativos imediatos, como o Chrome, o Firefox, fossem compilados estaticamente, o requisito de memória adicional para o sistema médio seria de alguns 100 MB. Um argumento que não tem muito a ver com os muitos sistemas GB atuais, de modo que a vinculação estática para aplicativos imediatos pode ser uma opção.
Há também os conceitos de espaço de troca e SSDs que permitem a troca / troca de maneira incrivelmente rápida, o que também ajuda a lidar com o requisito de memória aumentado.
O problema da glibc discutido aqui não é realmente resolvido através de links estáticos, mas para aplicações como navegador web é concebível um tipo de formato de distribuição auto-contido, onde o protocolo X, algum daemon de som e alguns métodos de kernel são a única interface. A vantagem seria menos incompatibilidades na versão da biblioteca.