1
对ld-linux.so黑客使用替代libc;更清洁的方法?
我有一个带有非常老的glibc的遗留系统,如果不进行大量测试/验证工作,就无法升级。 我现在需要多次在该系统上运行较新的程序(例如Java 1.7)。我选择了chroot解决方案,其中打包了所有需要的库,并在chroot中运行服务。 chroot的限制非常大,我宁愿尝试使用LD_LIBRARY_PATH解决问题。不幸的是,我libc.so.6: cannot handle TLS data在尝试时遇到错误。 事实证明,我也需要/lib/ld-linux.so.2chroot的。这有效: LD_LIBRARY_PATH=/home/chroot/lib /home/chroot/lib/ld-linux.so.2 /home/chroot/bin/program 但是,java通过检查/proc/self/cmdline以确定从何处加载其库来挫败我的窍门,如果二进制文件未命名为“ bin / java”,该方法将失败。Java在启动过程中也会执行自身,这使事情变得更加复杂。 在最后努力,使这项工作,我打开了Java二进制,十六进制编辑器和替换字符串/lib/ld-linux.so.2用/home/chroot/ld.so(并作出一个符号链接ld-linux.so.2),和它的工作! 但是我想每个人都会同意,将每个新二进制文件的路径重写为嵌套系统的绝对路径是一个巨大的麻烦。 有谁知道使用自定义库路径(包括自定义ld-linux.so)的更简洁方法?