Canadian Cross

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

1

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)
>
>
>

1

> PATH=$linpre/bin:$PATH // linpre = compiler 2)

2

> export PATH

3

> 

4

> cd $dirbld_gcc

5

> 

6

> ../$dirsrc_gcc/configure --build=$build --host=$host --target=$target

7

> --prefix=$prefix  \

8

> --disable-nls --disable-shared --disable-threads

9

> --disable-win32-registry             \

10

> --with-newlib

11

> --with-headers=$dirbld_root/$dirsrc_newlib/newlib/libc/include        \

12

> --with-dwarf2 --with-float=soft --disable-interwork --disable-multilib

13

> \

14

> --with-cpu=arm7tdmi --with-gcc --with-gnu-ld --with-gnu-as

15

> \

16

> --disable-libssp --disable-libstdcxx-pch --disable-libmudflap

17

> --disable-libgomp       \

18

> --enable-languages=c,c++

19

> \

20

> -v

21

> \

22

>> __01_make_cnfg_gcc.log 2>&1

23

>

1

echo $build

2

echo $host

3

echo $target

4

echo $prefix

5

echo $dirbld_root

6

echo $dirsrc_newlib

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

1

--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

1

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

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

Johann