Hans schrieb:
> hab's jetzt nochmals probiert und bekomm den Fehler "mcpu=arm9" not
> recognized bereits beim Installieren der newlib.
Mögliche Fehlerquelle ist — wie oben bereits geschrieben — daß du nur
Teile des Compilers generierst und installierst und andere weglässt.
Damit erhält du natürlich keinen funktionsfähigen Compiler. D.h. die
Compiler-Kerne (cc1, cc1plus) funktionieren zwar, du kannst aber keine
ablauffähigen Programme damit erzeugen.
Ein paar Grundregeln für GCC:
- Niemals in einem Unterverzeichnis der Quellen configure aufrufen
- Immer in einem leeren build-Verzeichnis generieren d.h.
configure starten. Vergiss "make clean" et. al!
- Auch für binutils wirds damit übersichtlicher
- Verwende für binutils und GCC die gleiche --prefix
Ober verwendest zu einmal --prefix=/foo und einmal
--prefix=/foo/ Ich weiß nicht ob das einen Unterschied macht,
aber man muss es ja auch nicht drauf anlegen.
Die Abgängigkeiten GMP/MPFR/MPC löse ich am liebsten dadurch auf, indem
sie zusammen mit GCC configured, erzeugt und installiert werden, siehe
[1]. Damit erhalten sie ein mit GCC konsistentes configure, und es
beeinflusst nicht die Systeminstallation.
Nach einfacher, als das Zeug von Hand runterzuladen, geht man ins
GCC-Quellverzeichnis und führt folgendes Skript aus:
1 | ./contrib/download_prerequesities
|
Fertig!
Danach braucht man sich nicht mehr um das Zeugs zu kümmern und hat auch
immer die für GCC empfohlene Version dieser Pakete.
Erst danach wird GCC configured; er erkennt dann daß diese Pakete da
sind.
Analog kann man die newlib miterzeugen lassen. Dazu linkst du die
Quellen als "newlib" in die GCC-Quellen rein, analog zu den GMP et al.
von oben. Beachte dazu, daß das GCC-configure die Konfiguration der
newlib macht, nicht das Tooplevel-configure der newlib. D.d. du links
nicht die oberste Ebene der newlib rein, sondern deren Unterverzeichnis
newlib.
Ditto für libgloss falls gewünscht.
Die Kommandos sehen dann ungefähr so aus:
Als erstes besorgst du die Quellen und machst sie nach
1 | ./source/binutils-2.22
|
2 | ./source/gcc-4.7.1
|
3 | ./source/newlib-x.y.z
|
Dann klinkst du die Abhängigkeiten rein, dach sieht das GCC-Verzeichnis
vereinfacht so aus:
1 | ./source/gcc-4.7.1/gmp
|
2 | ./source/gcc-4.7.1/mpfr
|
3 | ./source/gcc-4.7.1/mpc
|
4 | ./source/gcc-4.7.1/newlib
|
Dann erzeugst du die build-Verzeichnisse:
1 | ./build/binutils-2.22-arm-eabi
|
2 | ./build/gcc-4.7.1-arm-eabi
|
Und dann configure aus diesen Verzeichnissen
1 | == binutils ==
|
2 | cd build/binutils-2.22-arm-eabi
|
3 | $ ../../binutils-2.22/configure --target=arm-eabi --prefix=/gnucompiler --enable-interwork
|
4 | $ make
|
5 | $ make install
|
1 | == GCC ==
|
2 | cd build/gcc-4.7.1-arm-eabi
|
3 | $ ../../gcc-4.7.1/configure --target=arm-eabi --prefix=/gnucompiler --enable-interwork --enable-multilib --enable-languages="c" --with-cpu=arm9
|
4 | $ make
|
5 | $ make install
|
Und die Option heisst --enable-multilib, nicht --enable-multlib. Bei
den anderen Optionen gehe ich davon aus daß du weisst was zu tust. Ich
kenn kein ARM und kann nix dazu sagen.
> Hat irgendwer noch eine Idee, an was das liegen könnte?
Ja, steht schon oben. Und in meiner letzten Antwort.
> Das soll angeblich ein Fehler sein, wenn der gcc nicht ordnungsgemäß
> installiert wurde.
Ja, du erzeugst nur Teile davon, und installierst nur Teile davon. Keine
gute Idee, es sei denn du brauchst sowas als GCC-Entwickler.
[1] http://gcc.gnu.org/install/download.html