GCC (Cross) findet Default-Include-Path nicht

[Schneemann]

Hi,

Ich baue mir gerade einen GCC-Crosscompiler für mein OS. GCC und Binutils habe ich erfolgreich kompiliert. Meine Libs habe ich nach $PREFIX/lib bzw. die Header nach $PREFIX/include kopiert. Wenn ich jetzt versuche mein Testprogramm zu kompilieren, bricht er ab, weil er meine Header nicht finden kann. Wenn ich denn Include-Path per -I an GCC gebe, funktioniert es. Meine Libs findet er auch nicht. Wenn ich GCC mit "--includedir $PREFIX/include" kompiliere verändert sich nichts. $PREFIX ist richtig, das habe ich schon mit -v ausprobiert.

 

[supersucker]

Offtopic + aus Interesse:

Was ist denn "dein OS"?

 

[Schneemann]

Offtopic + aus Interesse:

Was ist denn "dein OS"?

http://jgraef.bplaced.net/meinos/
Das letzte Floppy-Image ist aber schon alt (noch alter Kernel) und den letzten Sourcecode traue ich mich kaum euch zu zeigen (also der Sourcecode-Stil spiegelt nicht den heutigen wieder)
meinOS (ja ein besserer Name ist mir wirklich nicht eingefallen) ist ein unix-ähnliches Mikrokernel-Betriebssystem. Mikrokernel bedeutet einfach nur, dass der Kernel zu einfach wie möglich gehalten wird, somit laufen alle Treiber im Userspace. Naja, im Moment macht meinOS halt noch nicht viel, Außer ein paar Treiber starten, die es zum Booten braucht.

Und ja, es ist wirklich ein richtiges Betriebssystem. Also ich intepretiere deine Anführungszeichen mal so, ob du daran zweifelst, ob es "mir" gehört oder überhaupt ein richtiges OS ist. Naja kann ich verstehen, da das Thema OS Development oft von (wie soll man sie anderst nennen) Noobs misbraucht wird.

 

[Tropezien]

Die default-Include und -Link-Pfade müssen bereits beim Bauen des Cross-Compilers mit angegeben werden. Um zu kontrollieren welche Pfade Dein Compiler per default verwendet ruf' einfach mal auf:

gcc -E -v /dev/null -

Welche Version des gcc willst Du denn cross bauen? Passen gcc, glibc, und binutils zusammen, sind also aufeinander abgestimmt?

Eine typische build-Reihenfolge für eine gcc-3.4.3 cross-toolchain ist:

1. binutils bauen
2. Linux-Header bauen (der gcc braucht einige Kernel-Headerfiles)
3. glibc-Header erzeugen und installieren
4. Eine bootstrap-Version des gcc erzeugen
5. glibc endgültig mit dem bootstrap-gcc bauen
6. gcc mit der neuen glibc bauen

Das Ganze natürlich mit einem Sack voller Argumente und Optionen.

Das wichtigste aber sind beim cross-build die drei Parameter build,host und target. Hierzu ein Zitat aus einem meiner Build-Skripte:

#
# some remarks on specifying --host=<host>, --target=<target> and --build=<build>
# kindly provided by Keith Marshall:
# 1) build
# this is *always* the platform on which you are running the build
# process; since we are building on Linux, this is unequivocally going to
# specify `linux', with the canonical form being `i686-pc-linux-gnu'.
#
# 2) host
# this is a tricky one: it specifies the platform on which whatever we
# are building is going to be run; for the cross-compiler itself, that's
# also `i686-pc-linux-gnu', but when we get to the stage of building the
# runtime support libraries to go with that cross-compiler, they must
# contain code which will run on the `i686-pc-mingw32' host, so the `host'
# specification should change to this, for the `runtime' and `w32api'
# stages of the build.
#
# 3) target
# this is probably the one which causes the most confusion; it is only
# relevant when building a cross-compiler, and it specifies where the code
# which is built by that cross-compiler itself will ultimately run; it
# should not need to be specified at all, for the `runtime' or `w32api',
# since these are already targetted to `i686-pc-mingw32' by a correct
# `host' specification.

Insbesondere target ist wichtig, weil damit in Verbindung mit prefix beim configure-run das spätere Zielverzeichnis für die Installation des gcc festgelegt wird. Diesen Pfad findet man dann wieder in der `gcc -E -v /dev/null -` Ausgabe von oben.

Das cross-building der toolchains hat mich schon manches graue Haar gekostet. Und praktisch mit jeder gcc/glibc/binutils-Kombination wird herumgebastelt und es funktioniert nicht mehr, was vorher problemlos lief. Nicht umsonst gibt es eine ganze Menge Lieferanten für (kostenpflichtige) cross-toolchains; da ist richtig Zeit und Know-How drin.

 

[marcellus]

Sollte das crosscompilen nicht unnötig sein, wenn meinOS elf kompatibel ist?

 

[Schneemann]

Sollte das crosscompilen nicht unnötig sein, wenn meinOS elf kompatibel ist?

Ich will aber, dass man Apps für meinOS bauen kann, ohne die ewig langen Parameterlisten, wo die ganzen Header uns Libs liegen. Das ist praktischer für große Apps zu portieren.

 

[Tropezien]

Sollte das crosscompilen nicht unnötig sein, wenn meinOS elf kompatibel ist?

Das ELF-Format gibt nur eine grundsätzliche Aufteilung von einzelnen Datenblöcken innerhalb einer Datei an. Dabei haben bestimmte Datenblöcke ein bestimmtes Format und können direkt interpretiert werden, z.B. der Header-Block. Aber die Code-Blöcke können zwar auf jeder Maschine (jedem Prozessor) gelesen, aber nicht ausgeführt werden. Damit diese Codeblöcke auch ausgeführt werden können, muss der Maschinencode des betreffenden Target-Prozessors enthalten sein. Und dazu wird i.A. ein Cross-Compiler verwendet. Vorausgesetzt natürlich ich habe unterschiedliche Prozessoren auf meiner Build- und meiner Target-Plattform.
Aber selbst wenn ich den gleichen Prozessortyp verwende heißt das noch lange nicht, dass ich einfach auf dem Build-Host übersetzte Programme auf dem Target laufen lassen kann. Dazu gehören dann auch noch die passenden Bibliotheken (entfällt beim statischen Linken). Diese müssen sowohl beim Linken als auch zur Laufzeit vorhanden sein.