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
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
/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?