傳統鏈接器（使用libc5）在Linux內核2.6.25上失敗

我們有一個使用libc5的傳統鏈接器，並且由於幾個因素，我們只有二進制文件而不是源文件。是的，版本控制可以將我們從目前的問題中拯救出來......目前我們正在使用我們的全套工具鏈和產品線，但這種特殊的馬早已不復存在。傳統鏈接器（使用libc5）在Linux內核2.6.25上失敗

此連接適用於Linux內核2.6.24，但在2.6.25（2.6.26和），它失敗的消息

 
    Virtual memory exceeded in `new'

我們與相關的遺留編譯器類似的問題，但隨着有些研究已經發現編譯器問題是由linux內核2.6.25中的「brk隨機化」引起的。造成這種情況的解決方法是設置一個sysctl的VAR和環境VAR：

 
    /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應用程序出現問題。

那麼，我能找到並安裝libc5版本的libg ++。so.27，還是有一些更好的方法來禁用brk隨機化，或者是內核2.6.24和2.6.25之間的另一個區別導致鏈接器問題？

編輯

見this所有這一切搜索的細節，我的最終解決。

來源

2009-04-27 JimKleck

這是什麼平臺，我知道64位內存管理代碼在x86-64/amd64上有一段時間後會影響libc的變化... – ewanm89 2009-04-27 22:28:00

它並不完全回答你的問題，但在你的情況下，我會創建一個已知的工作libc + libstdC++組合，甚至內核+ libc + libstdC++的chroot（在這種情況下，你需要一個虛擬機，顯然）。這樣，您可以相對容易地嘗試事情，而不會中斷其他任何事情。

與舊庫兼容的最好方法就是使用這個舊庫，畢竟它只是一個工具鏈問題，使用某種jail/chroot /虛擬機應該不會太多有問題嗎？

來源

2009-04-28 05:01:53

傳統鏈接器（使用libc5）在Linux內核2.6.25上失敗

回答

相關問題