Forum: Compiler & IDEs Canadian Cross


von Mott H. (Gast)


Lesenswert?

Hallo alle miteinander,

ich versuche derzeit die aktuelle GCC-4.4.0 inkl. BINUTILS-2.19.51 und 
NEWLIB-1.17.0 in Form eines Canadian Cross (Build=Linux; Host=MinGW; 
Target=ARM) zu bauen. Unter Berücksichtigung verschiedener Beiträge im 
Netz, z.B. 
http://www.kegel.com/crosstool/current/doc/crosstool-howto.html#canadian, 
habe ich es bereits so weit gebracht, dass die ersten zwei Punkte eines 
solchen Canadian Cross Builds
  1. Compiler bauen/installieren der auf dem Build-System läuft und Code 
für den Host erzeugt
  2. Compiler bauen/installieren der auf dem Build-System läuft und Code 
für das Target erzeugt
erledigt sind.
Beim dritten Teil - einen Compiler bauen der auf dem Host-System läuft 
und Target-Code erzeugt - habe ich allerdings einige Schwierigkeiten.
Zunächst haperte es daran, das im Stage2-Build der GCC "limits.h" 
angeblich nicht gefunden werden konnte, was ich aber mit 
http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01178.html beheben konnte. 
Mit diesem Patch erhalte ich jetzt aber folgende Fehlermeldung:

1
make[3]: Betrete Verzeichnis '/home/forseti/Development/gcc-4.4.0_build_win/gcc'
2
arm-elf-cc -nostdinc -isystem /home/forseti/Development/gcc-4.4.0_build_win/./gcc/include -isystem /home/forseti/Development/gcc-4.4.0_build_win/./gcc/include-fixed -B/home/forseti/Development/gcc-4.4.0_build_win/arm-elf/newlib/ -isystem /home/forseti/Development/gcc-4.4.0_build_win/arm-elf/newlib/targ-include -isystem /home/forseti/Development/gcc-4.4.0/newlib/libc/include -O2 -g -O2 -pipe -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition  -isystem ./include  -I. -I/home/forseti/Development/gcc-4.4.0_build_win/arm-elf/libgcc -I../../gcc-4.4.0/gcc -I../../gcc-4.4.0/gcc//home/forseti/Development/gcc-4.4.0_build_win/arm-elf/libgcc -I../../gcc-4.4.0/gcc/../include -I../../gcc-4.4.0/gcc/../libcpp/include -I/home/forseti/Development/gcc-4.4.0_build_win/./gmp -I/home/forseti/Development/gcc-4.4.0/gmp -I/home/forseti/Development/gcc-4.4.0_build_win/./mpfr -I/home/forseti/Development/gcc-4.4.0/mpfr  -I../../gcc-4.4.0/gcc/../libdecnumber -I../../gcc-4.4.0/gcc/../libdecnumber/dpd -I../libdecnumber   -g -O2 -pipe -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-toplevel-reorder -fno-tree-vectorize   \
3
    -c ../../gcc-4.4.0/gcc/crtstuff.c -DCRT_BEGIN \
4
    -o /home/forseti/Development/gcc-4.4.0_build_win/arm-elf/libgcc/crtbegin.o
5
In file included from /home/forseti/Development/gcc-4.4.0/newlib/libc/include/stdio.h:46,
6
                 from ../../gcc-4.4.0/gcc/tsystem.h:87,
7
                 from ../../gcc-4.4.0/gcc/crtstuff.c:63:
8
/home/forseti/Development/gcc-4.4.0/newlib/libc/include/sys/types.h:126: error: expected identifier or '(' before 'char'
9
make[3]: *** [/home/forseti/Development/gcc-4.4.0_build_win/arm-elf/libgcc/crtbegin.o] Fehler 1
10
make[3]: Verlasse Verzeichnis '/home/forseti/Development/gcc-4.4.0_build_win/gcc'
11
make[2]: *** [gcc-extra-parts] Fehler 2
12
make[2]: Verlasse Verzeichnis '/home/forseti/Development/gcc-4.4.0_build_win/arm-elf/libgcc'
13
make[1]: *** [all-target-libgcc] Fehler 2
14
make[1]: Verlasse Verzeichnis '/home/forseti/Development/gcc-4.4.0_build_win'
15
make: *** [all] Fehler 2

Ich denke das ich mich nicht zu weit aus dem Fenster lehne wenn ich 
einfach mal so annehme das die "types.h" der NEWLIB keine Syntax-Fehler 
enthält.
Aber was ist dann los? Könnt ihr mir helfen?

Vielen Dank
Mott

PS: Könnte das verunglückte 
"-I../../gcc-4.4.0/gcc//home/forseti/Development/gcc-4.4.0_build_win/arm 
-elf/libgcc"  die Ursache sein; ... siehe die 2., lange Zeile in der 
Fehlermeldung wo die Textfarbe auf grau wechselt. Was/Wo könnte die 
Ursache dafür sein?

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

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

von Mott H. (Gast)


Angehängte Dateien:

Lesenswert?

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 ?!?
- 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
> ich hab mal meine beiden Build-Scripts für Schritt 2) und 4) angehängt

Ich hoffe mit diesen neuen Auskünften könnt ihr vielleicht noch mehr 
Tips geben.

Danke
Mott

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

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

von Mott H. (Gast)


Lesenswert?

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 --prefix=$prefix  \
7
--disable-nls --disable-shared --disable-threads --disable-win32-registry             \
8
--with-newlib --with-headers=$dirbld_root/$dirsrc_newlib/newlib/libc/include        \
9
--with-dwarf2 --with-float=soft --disable-interwork --disable-multilib                \
10
--with-cpu=arm7tdmi --with-gcc --with-gnu-ld --with-gnu-as                              \
11
--disable-libssp --disable-libstdcxx-pch --disable-libmudflap --disable-libgomp       \
12
--enable-languages=c,c++                                                              \
13
-v                                                                                    \
14
> __01_make_cnfg_gcc.log 2>&1

> Ich versteh auch nicht, wozu man Build-Skripte braucht. Mit einem
> configure / make all install ist's doch getan.

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

Mott

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

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

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.