Legacy-Linker (uses libc5) schlägt auf Linux-Kernel 2.6.25

Question

Wir haben einen Legacy-Linker, der libc5 verwendet, und aufgrund mehrerer Faktoren haben wir nur die Binärdatei und nicht die Quelle. Ja, die Versionskontrolle hätte uns von unserem aktuellen Problem gerettet ... das jetzt für unsere gesamte Werkzeugkette und Produktlinie verwendet wird, aber dieses spezielle Pferd ist schon lange weg.

Dieser Linker arbeitet auf Linux-Kernel 2.6.24, aber auf 2.6.25 (und 2.6.26) es scheitert mit der Meldung

 
    Virtual memory exceeded in `new' 

Wir sind mit dem entsprechenden Legacy-Compiler hatten ein ähnliches Problem, aber mit einige stackoverflow.com answers und viel Forschung haben entdeckt, dass das Compiler-Problem durch die "brk randomization" in Linux Kernel 2.6.25 verursacht wurde. Die Abhilfe für das ist ein sysctl Vars zu setzen und eine Umgebung var:

 
    /proc/sys/kernel/randomize_va_space = 0 or 1 
    setenv MALLOC_TOP_PAD_ 536870912 

Dies ist jedoch nicht die Linker helfen.

Ich habe aus mit „ldd“ festgestellt, dass der Linker mehr gemeinsam genutzte Bibliothek Abhängigkeiten hat (der Compiler hatte nur die 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) 

Und ich habe gelesen, dass ich muß möglicherweise installieren die libc5-Version von libg ++. so.27. Ich zögere, das zu tun, da ich nicht weiß, ob das die neueste libg ++ .so.27 überschreibt und Probleme für nicht-libc5-Anwendungen verursacht.

Also, finde und installiere ich die libc5 Version von libg ++. So.27, oder gibt es eine bessere Möglichkeit die randomisierung von brk zu deaktivieren, oder gibt es einen anderen Unterschied zwischen Kernel 2.6.24 und 2.6.25 der das verursacht Linkerproblem?

bearbeiten

Siehe this für alle Details dieser Suche, und meine endgültige Auflösung.

Answer 1

Es beantwortet Ihre Frage nicht genau, aber in Ihrer Situation würde ich eine Chroot mit einer bekannten libc + libstdC++ -Kombination erstellen, oder sogar kernel + libc + libstdC++ (in diesem Fall brauchen Sie eine virtuelle Maschine) offensichtlich). Auf diese Weise können Sie Dinge relativ einfach ausprobieren, ohne etwas anderes zu stören.

Der beste Weg, mit einer alten Bibliothek kompatibel zu sein, ist diese alte Bibliothek zu verwenden, und da es "nur" ein Toolchain-Problem ist, sollte eine Art von jail/chroot/virtueller Maschine nicht zu viel sein von einem Problem?