Eu tenho um sistema legado com um glibc muito antigo, que não podemos atualizar sem incorrer em uma montanha de testes / validação.
Eu precisei executar programas mais recentes (como o Java 1.7) nesse sistema várias vezes agora. Eu optei por uma solução chroot, onde empacotei todas as bibliotecas necessárias e executei um serviço em um chroot.
O chroot é muito limitado, e eu prefiro tentar resolver o problema com o LD_LIBRARY_PATH. Infelizmente, recebo um erro sobre libc.so.6: cannot handle TLS data quando tento isso.
Acontece que eu preciso do /lib/ld-linux.so.2 do chroot também. Isso funciona:
LD_LIBRARY_PATH=/home/chroot/lib /home/chroot/lib/ld-linux.so.2 /home/chroot/bin/program
No entanto, java anula meu truque inspecionando /proc/self/cmdline para determinar de onde carregar suas bibliotecas, o que falha se o binário não tiver o nome 'bin / java'. Também o próprio java execs durante a inicialização, complicando ainda mais as coisas.
Em uma tentativa desesperada de fazer esse trabalho, eu abri o binário java com um editor hexadecimal e substituí a string /lib/ld-linux.so.2 com /home/chroot/ld.so (e tornei isso um link simbólico para ld-linux.so.2 ), e funcionou!
Mas acho que todos concordariam que é um kludge massivo reescrever o caminho de cada novo binário para um caminho absoluto do sistema aninhado.
Alguém sabe uma maneira mais clara de usar um caminho de biblioteca personalizado incluindo um ld-linux.so?
personalizado?