2

我们有一个使用 libc5 的旧版链接器，由于多种因素，我们只有二进制文件而不是源代码。是的，版本控制可以让我们摆脱当前的问题......现在我们的完整工具链和产品线都在使用它，但是这匹特别的马早已不复存在。

此链接器适用于 linux 内核 2.6.24，但在 2.6.25（和 2.6.26）上失败并显示消息

    “新”中超出虚拟内存

我们在使用相应的旧版编译器时遇到了类似的问题，但是通过一些 stackoverflow.com的答案和大量研究发现，编译器问题是由 linux 内核 2.6.25 中的“brk 随机化”引起的。解决方法是设置 sysctl vars 和 environment var：

    /proc/sys/kernel/randomize_va_space = 0 或 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 应用程序出现问题。

那么，我是否找到并安装了 libc5 版本的 libg++.so.27，或者是否有更好的方法来禁用 brk 随机化，或者内核 2.6.24 和 2.6.25 之间是否存在导致链接器问题的另一个区别？

编辑

有关此搜索的所有详细信息以及我的最终解决方案，请参阅此内容。

4

1 回答 1

4

它不能准确回答您的问题，但在您的情况下，我会创建一个具有已知可工作的 libc + libstdc++ 组合的 chroot，甚至是 kernel+libc+libstdc++（在这种情况下，您显然需要一个虚拟机）。这样，您可以相对轻松地尝试事情，而不会破坏其他任何事情。

毕竟，与旧库兼容的最好方法是使用这个旧库，因为它“只是”一个工具链问题，所以使用某种监狱/chroot/虚拟机应该不是什么大问题？

于 2009-04-28T05:01:53.080 回答