我们有一个使用 libc5 的旧链接器，由于多种因素，我们只有二进制文件，没有源代码。是的，版本控制可以让我们摆脱当前的问题……现在我们的完整工具链和产品线都在使用版本控制，但是这匹特殊的马早已不复存在了。
此链接器适用于 Linux 内核 2.6.24，但在 2.6.25(和 2.6.26)上它失败并显示消息
Virtual memory exceeded in `new'
我们在相应的旧版编译器上也遇到了类似的问题，但在某些 stackoverflow.com answers 上却遇到了类似的问题。大量研究发现，编译器问题是由Linux内核2.6.25中的“brk随机化”引起的。解决方法是设置 sysctl 变量和环境变量:
/proc/sys/kernel/randomize_va_space = 0 or 1
setenv MALLOC_TOP_PAD_ 536870912
但是，这对链接器没有帮助。
我通过使用“ldd”发现链接器具有更多共享库依赖项(编译器只有 libc.so.5):
libg++.so.27 => /usr/lib/libg++.so.27 (0xb7eca000)
libstdc++.so.27 => /usr/lib/libstdc++.so.27 (0xb7e99000)
libm.so.5 => /lib/libm.so.5 (0xb7e90000)
libc.so.5 => /lib/libc.so.5 (0xb7dd3000)
而且我了解到我可能必须安装 libg++.so.27 的 libc5 版本。我犹豫是否要这样做，因为我不知道这是否会覆盖最新的 libg++.so.27 并导致非 libc5 应用程序出现问题。
那么，我是否找到并安装 libg++.so.27 的 libc5 版本，或者是否有更好的方法来禁用 brk 随机化，或者内核 2.6.24 和 2.6.25 之间是否存在导致链接器的另一个差异有问题吗？
编辑
参见this了解这次搜索的所有细节以及我的最终解决方案。
最佳答案
它并没有准确回答你的问题，但在你的情况下，我会使用已知可用的 libc + libstdc++ 组合创建一个 chroot，甚至是 kernel+libc+libstdc++ (在这种情况下你需要一个虚拟机，明显地)。这样，您就可以相对轻松地尝试一些事情，而不会干扰其他任何事情。
与旧库兼容的最好方法是使用这个旧库，毕竟，由于它“只是”一个工具链问题，所以使用某种 jail /chroot/虚拟机不应该太多有问题吗？
关于linux - 旧版链接器(使用 libc5)在 Linux 内核 2.6.25 上失败，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/795510/