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