2

libc5 を使用する従来のリンカがありますが、いくつかの要因により、ソースではなくバイナリしかありません。はい、バージョン管理があれば現在の問題は解決できたはずです...現在、この問題はツール チェーンと製品ライン全体で使用されていますが、この特定の馬はとうの昔に姿を消しました。

このリンカは Linux カーネル 2.6.24 で動作しますが、2.6.25 (および 2.6.26) では失敗し、次のメッセージが表示されます。

    「new」で仮想メモリを超えました

対応するレガシー コンパイラにも同様の問題がありましたが、stackoverflow.com の回答と多くの調査により、コンパイラの問題は Linux カーネル 2.6.25 の「brk ランダム化」が原因であることが判明しました。その回避策は、sysctl 変数と環境変数を設定することです。

    /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 以外のアプリで問題を引き起こすかどうかわからないので、私はそれをするのをためらっています。

では、libg++.so.27 の libc5 バージョンを見つけてインストールするか、brk のランダム化を無効にするより良い方法があるか、またはリンカーの問題を引き起こしているカーネル 2.6.24 と 2.6.25 の間に別の違いがありますか?

編集

この検索の詳細と私の最終的な解決策については、こちらを参照してください。

4

1 に答える 1

4

それはあなたの質問に正確には答えませんが、あなたの状況では、動作することが知られている libc + libstdc++ の組み合わせ、または kernel+libc+libstdc++ で chroot を作成します (この場合、明らかに仮想マシンが必要です)。このようにして、他のことを中断することなく、比較的簡単に試すことができます。

古いライブラリとの互換性を維持するための最良の方法は、結局のところ、この古いライブラリを使用することです。これは「単なる」ツールチェーンの問題であるため、ある種の刑務所/chroot/仮想マシンを使用することはそれほど問題ではありませんか?

于 2009-04-28T05:01:53.080 に答える