Erstellen von GCC mit glibc an einem nicht standardmäßigen Speicherort ohne root

8

Ich habe ein System, auf das ich keinen Root-Zugriff habe, aber ich muss die aktuelle Version von GCC (4.7.2) installieren.

Das System führt einen x86_64 Build von Linux 2.6.18 aus und hat bereits GCC 4.1 (ohne C ++ Unterstützung, obwohl --version sagt, dass es damit gebaut wurde).

BEARBEITEN SIE 5: An diesem Punkt sind die folgenden Schritte nur eine Reihe von Dingen, die ich ausprobiert habe. Ich habe seitdem ein paar Mal sauber gemacht. Ich suche jemanden, um die genaue Reihenfolge zu detaillieren, die ich benötige, um alles mit allen erforderlichen Schaltern zu machen.

Dies ist der Prozess, den ich bis jetzt durchlaufen habe (wo ROOT ein Ordner in meinem Home-Verzeichnis ist)

%Vor%

Gepatchte Glibc mit Patch von Ссылка (korrigiert Zeilennummern für 2.14)

%Vor%

Die Flaggen, die ich hinzugefügt habe, sollten undefined reference to '__isoc99_sscanf' loswerden. Ich weiß nicht, welche Kombination von Flags eigentlich notwendig war, um das zu beheben, aber es behob das Problem mit diesen Flags.

%Vor%

Jetzt bekomme ich diesen Fehler während des GCC-Builds:

%Vor%

Der Fehler macht Sinn, weil libc in / lib64 Version 2.5 ist, aber ich weiß nicht, wie ich GCC dazu bringen kann, den von mir gebauten zu verwenden, der auf $ ROOT / lib installiert wurde.

EDIT 1: Das Hinzufügen von -rpath hat nicht geholfen, aber ich habe meine lib-Verzeichnisse zu LD_RUN_PATH und LD_LIBRARY_PATH hinzugefügt. Mit diesen Set konnte ich nichts ausführen, da ich den Fehler [program_name]: error while loading shared libraries: /home/mrambiguous/root/lib/libc.so.6: ELF file OS ABI invalid

bekommen habe

Eine weitere merkwürdige Sache ist, dass ich, als ich den -rpath-Vorschlag ausprobierte, Fehler von GCC über nicht erkannte Befehlszeilenoptionen (wie -V) bekam. Ich musste es einstellen, um den GCC 4.1 des Systems zu verwenden. Jetzt bin ich mir nicht sicher, ob mein erster Build von GCC irgendwie beschädigt wurde oder ob er jemals überhaupt benutzt wurde.

EDIT 2: Ich habe gerade libc.so.6 in vim geöffnet, um zu sehen, ob ich irgendwas über den ABI im Klartext finden kann und es ist dort mit den Copyright-Informationen. libc ABIs: UNIQUE IFUNC

Es bestätigt auch, dass GCC 4.7.2 in demselben Textblock funktioniert hat. Compiled by GNU CC version 4.7.2

BEARBEITEN 3: $ ROOT entfernt, alles neu installiert, dasselbe Problem beim Nicht-Erkennen von -V und -qversion als gültige Optionen.

EDIT 4: Ich habe versucht, den ELF-Header mit brandelf -t SVR4 libc.so.6 zu bearbeiten, aber das gibt mir nur einen neuen Fehler unexpected PLT reloc type 0x25

    
Austin Wagner 01.12.2012, 17:04
quelle

1 Antwort

4

Ich habe es eilig, deshalb kann ich Ihre Fehlermeldungen nicht im Detail analysieren.

Neuere glibc und alte glibc sind nicht nur ABI inkompatibel, sondern auch Header, siehe gcc bug 52922 .

Daher führt jedes Mischen zu Fehlern, wie Sie es kennen, Sie müssen sehr vorsichtig sein.

Handabstimmung ist hoffnungslos langweilig.

Wenn Sie gcc-4.7.2 verwenden möchten, empfehle ich Ihnen Gentoo-Präfix . Ich habe viele Instanzen von Gentoo Prefix auf RHEL 5 (die 2.6.18 Kernel, gcc-4.1 und glibc-2.5 wie Sie haben). Dies kompiliert gcc-4.7.2 auf glibc-2.5.

Wenn Sie Spaß am Verwenden neuerer Glibcs ​​haben möchten, sehen Sie sich Prefix / libc an. Es ist jedoch ein Work-in-Progress. Erwarten Sie viele Bruchstellen. Aber es wird kein großer Nachteil sein, wenn Sie versuchen, eine moderne Toolchain von Hand zusammenzustellen, oder?

    
heroxbd 01.07.2013, 14:15
quelle

Tags und Links