Ich erinnere mich da an Probleme in fixincludes, die den Fall eines
Canadian nicht korrekt behandelten:
  http://gcc.gnu.org/ml/gcc-help/2009-04/msg00023.html

Du hast 4 Compiler im Spiel (host-harget):

1) linux->linux: erzeugt 2) und 3)
2) linux->arm: "normaler" x-compiler, brauchst du für die Target-Libs
von 4)
3) linux->mingw32: compiler für den x-build und libiberty (Host-Lib) von
4)
4) mingw32-arm: den willst du erstellen, zudem die Target-Libs (libgcc,
newlib, libgloss, ...)

Wie 2) erzeugt wird ist klar, für 3) gibt's build-Skripte bei MinGW. Als
erstes machst du 2) und 3), die sind unabhängig voneinander -- bis auf
die Tatsache, daß sie beide 1) zum Erzeugen brauchen.

Beim Build von 4) muss 3) im Pfad sein und CC darf nicht gesetzt sein,
ansonsten wird der falsche Compiler genommen. 2) muss im Pfas dein oder
per --build-time-tools erreichbar sein, dito binutils

Am einfachsten ist es, wenn du die Subpacks ins Toplevel-Direktory
reinlinkst undin-tree erzeugst, das ist einfacher als separate Builds
von newlib, GMP, MPFR. Für binutils geht das aber leider nicht wegen
Inkompatibilitäten in den libibertys von GCC bzw. binutils.

Wie ist der mingw32-arm denn configured?

Johann

Mott H. schrieb:
> Hi Johann,
>
> vielen Dank. Werde versuchen diese neuen Infos gleich anzuwenden.
> Vorher noch zu deinen Fragen bzw. weitere Infos meinerseits:
> - Build  = Linux Mint 6 (Felicia) bzw. i686-linux-gnu
>   Host   = Windows/MSYS bzw. i586-mingw32msvc (v4.2.1-sjlj)
>   Target = arm-elf
> - mingw32 ist per Packetverwaltung installiert
>> um 1) und 3) brauchte ich mich also nicht weiter kümmern
> - zum erstellen von 2) und 4) kopiere ich NEWLIB, GMP und MPFR bereits
>   jeweils ins GCC-Root-Verzeichnis
> - zum Bau von 4) habe ich 2) zum Pfad hinzugefügt;
>   mit 3) (EXE-Files) könnte die Build-Umgebung doch nichts anfangen ?!?

Natürlich, mit dem Compiler muss doch 4) erstellt werden. 3) erzeugt
.exe-Files (bzw. Bibliotheken für die Host-Plattform wie libiberty). Es
ist selber ein Cross-Compiler, der unter Linux läuft.

> - bis auf CFLAGS und CXXFLAGS setze ich keinerlei Umgebungsvariablen;
>   das sollte - soweit ich Verstanden habe - die Verwendung der
>   configure-Parameter --build, --host und --target automatisch regeln
Sicherheit bringt

echo $CC

>> ich hab mal meine beiden Build-Scripts für Schritt 2) und 4) angehängt

Interessiert hätte mich das configure für 4), wollte mich jetzt nicht
durch irgendwelche Skripte hangeln... Ich versteh auch nicht, wozu man
Build-Skripte braucht. Mit einem configure / make all install ist's doch
getan.

Johann

Mott H. schrieb:
> Hi Johann,
>
>>> - zum Bau von 4) habe ich 2) zum Pfad hinzugefügt;
>>>   mit 3) (EXE-Files) könnte die Build-Umgebung doch nichts anfangen ?!?
>
>> Natürlich, mit dem Compiler muss doch 4) erstellt werden. 3) erzeugt
>> .exe-Files (bzw. Bibliotheken für die Host-Plattform wie libiberty). Es
>> ist selber ein Cross-Compiler, der unter Linux läuft.
>
> Sorry. Hab mich da in der Logik verheddert. Du hast natürlich Recht.
>
>> Interessiert hätte mich das configure für 4)
>
>
>

> PATH=$linpre/bin:$PATH // linpre = compiler 2)
> export PATH
> 
> cd $dirbld_gcc
> 
> ../$dirsrc_gcc/configure --build=$build --host=$host --target=$target
> --prefix=$prefix  \
> --disable-nls --disable-shared --disable-threads
> --disable-win32-registry             \
> --with-newlib
> --with-headers=$dirbld_root/$dirsrc_newlib/newlib/libc/include        \
> --with-dwarf2 --with-float=soft --disable-interwork --disable-multilib
> \
> --with-cpu=arm7tdmi --with-gcc --with-gnu-ld --with-gnu-as
> \
> --disable-libssp --disable-libstdcxx-pch --disable-libmudflap
> --disable-libgomp       \
> --enable-languages=c,c++
> \
> -v
> \
>> __01_make_cnfg_gcc.log 2>&1
> 

echo $build
echo $host
echo $target
echo $prefix
echo $dirbld_root
echo $dirsrc_newlib

> Die (sehr kurzen und einfachen) Build-Scripte enthalten jeweils die
> configures und makes der BINUTILS, der GCC und der NEWLIB.

--with-newlib --with-headers=

Ist überflüssig bzw. stören, wenn du wie gesagt einen in-tree build der
newlib machen willst. Dazu einfach nen Softlink auf die newlib-Quelle
(da stehen dann newlib, libgloss, ...) im GCC-Toplevel. GCC erkennt die
Subpacks automatisch, da musste ich noch nie was extra drehen. Den
Problemen einer von Hand erzeugten canadian-cross-newlib würde ich aus
dem Wege gehen.

newlib kommt doch mit deiner Target-Plattform zurecht, oder?

Zu

 --disable-multilib --with-cpu=arm7tdmi 

kann ich nix sagen, weil ich immer mit Multilibs erzeuge (nicht für ARM,
sondern was privates :-)).

Johann