Using alternate libc with ld-linux.so hacks; cleaner method?

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?