I have a legacy system with a very old glibc, which we can't upgrade without incurring a mountain of testing/validation work.
I have needed to run newer programs (such as Java 1.7) on that system several times now. I opted for a chroot solution, where I package up all the needed libs, and run a service in a chroot.
The chroot is very limiting though, and I'd rather try to solve the problem with LD_LIBRARY_PATH. Unfortunately, I get an error about libc.so.6: cannot handle TLS data
when I try that.
It turns out I need the /lib/ld-linux.so.2
from the chroot as well. This works:
LD_LIBRARY_PATH=/home/chroot/lib /home/chroot/lib/ld-linux.so.2 /home/chroot/bin/program
However, java
foils my trick by inspecting /proc/self/cmdline
to determine where to load its libraries from, which fails if the binary wasn't named 'bin/java'. Also java execs itself during startup, further complicating matters.
In a last-ditch attempt to make this work, I opened the java binary with a hex editor and replaced the string /lib/ld-linux.so.2
with /home/chroot/ld.so
(and made that a symlink to ld-linux.so.2
), and it worked!
But I think everyone would agree that it is a massive kludge to rewrite the path of every new binary to an absolute path of the nested system.
Does anyone know a cleaner way to use a custom library path including a custom ld-linux.so?