Benutzer:Jidder/Cross-Compiler unter MinGW — Änderungen 3314 → 3315

Zeile 1: Zeile 1:
−
Da ich Vista benutze, habe ich leider keinen nativen Compiler, der [[ELF]]-Dateien ausspuckt. Da ich nicht dazu komme den Artikel [[Crosscompiler für Windows]] zu überarbeiten, halte ich hier mal ein paar Gedanken und Hinweise fest. Ich hoffe jemand kann sich damit ein paar Stunden rumgefrickel ersparen. Für mich waren (und sind) die Lösungen für die ganzen Problemchen nicht unmittelbar durchschaubar. Vermutlich rühren die meisten eh von der Wahl eines so exotischen Host-Systems her ..
+
Da ich Vista benutze, habe ich leider keinen nativen Compiler, der [[ELF]]-Dateien ausspuckt. Da ich nicht dazu komme den [[Crosscompiler für Windows|Cross Compiler für LOST]] zu überarbeiten, halte ich hier mal ein paar Gedanken und Hinweise fest. Das hier ist kein Tutorial, sondern eine Sammlung von Ergänzungen zu den üblichen Tutorials wie zum Beispiel unsere [[Cross-Compiler]]-Bauanleitung oder die für eine [http://wiki.osdev.org/OS_Specific_Toolchain OS Specific Toolchain] von den Kollegen bei [http://wiki.osdev.org osdev.org].
 +
 
 +
Ich hoffe ich kann mit diesen Tipps jemandem ein wenig Rumgefrickel ersparen. Für mich waren (und sind) die Lösungen für die ganzen Problemchen nicht unmittelbar durchschaubar, weil ich keine Ahnung von autoconf/configure/make habe. Deswegen sind diese Anleitungen
  
 
== Binutils ==
 
== Binutils ==
−
Der aktuelle MinGW kommt mit texinfo 4.11, das is auf Grund eines [http://sourceware.org/bugzilla/show_bug.cgi?id=5021 Bugs] allerdings zu neu für binutils. Wer gerne mit Patches spielt und mit den autotools umgehen kann, der kann den Patch natürlich anwenden. Windoofnutzer wie meine Wenigkeit können nach dem ./configure auch einfach die im build-Verzeichnis erzeugte Makefile nachbearbeiten und die Zeile suchen, die ungefähr so aussieht:  
+
Der aktuelle MinGW kommt mit texinfo 4.11, das ist auf Grund eines [http://sourceware.org/bugzilla/show_bug.cgi?id=5021 Bugs] allerdings zu neu für binutils 2.18. Wer gerne mit Patches spielt und mit den autotools umgehen kann, der kann den entsprechenden Patch natürlich anwenden. Windoof-Nutzer wie meine Wenigkeit können nach dem ./configure auch einfach die im Build-Verzeichnis erzeugte Makefile nachbearbeiten und die Zeile suchen, die ungefähr so aussieht:  
 
  MAKEINFO = /PATH_TO/JIDDEROS_CC_SRC/binutils-2.18/missing makeinfo
 
  MAKEINFO = /PATH_TO/JIDDEROS_CC_SRC/binutils-2.18/missing makeinfo
 
und sie durch diese ersetzen:
 
und sie durch diese ersetzen:
 
  MAKEINFO = makeinfo
 
  MAKEINFO = makeinfo
−
Wenn man wirklich kein makeinfo hat, kann man sich auch an der Datei /PATH_TO/JIDDEROS_CC_SRC/binutils-2.18/missing zu schaffen machen, und da nach ''makeinfo)'' suchen und dann da drunter das erste Vorkommen von ''test -f $file || exit 1'' löschen.
+
Wenn man tatsächlich kein makeinfo hat, kann man sich auch an der Datei /PATH_TO/JIDDEROS_CC_SRC/binutils-2.18/missing zu schaffen machen, und da nach ''makeinfo)'' suchen und dann da drunter das erste Vorkommen von ''test -f $file || exit 1'' löschen.
  
 
== GCC ==
 
== GCC ==
Zeile 37: Zeile 39:
 
*config.sub wie [http://wiki.osdev.org/OS_Specific_Toolchain#config.sub im Tutorial beschrieben] um das Target ergänzen, wenn man sich ein eigenes ausgedacht hat, und nicht einfach für i386-elf oder so kompiliert.
 
*config.sub wie [http://wiki.osdev.org/OS_Specific_Toolchain#config.sub im Tutorial beschrieben] um das Target ergänzen, wenn man sich ein eigenes ausgedacht hat, und nicht einfach für i386-elf oder so kompiliert.
  
−
*Warum auch immer kann man der ./configure den Cross Compiler nicht korrekt verklickern, und meiner bockt mit den Include-Pfaden rum, wenn man ihn einfach nur als gcc.exe (statt i586-pc-JIDDEROS-gcc.exe) aufruft. Ich hab dann einfach gcc.exe und cc1.exe und deren Freunde (also die .exe-Dateien in deren Verzeichnissen) in das selbe Verzeichnis wie i586-pc-JIDDEROS-gcc.exe kopiert, und das natürlich in die PATH-Variable eingetragen.
+
*Warum auch immer kann man dem ./configure den Cross Compiler nicht korrekt verklickern, und meiner bockt darüberhinaus noch mit den Include-Pfaden rum, wenn man ihn einfach nur als gcc.exe (statt i586-pc-JIDDEROS-gcc.exe) aufruft. Pragmatisch wie ich bin, hab ich einfach gcc.exe und cc1.exe und deren Freunde (also die .exe-Dateien in deren Verzeichnissen) in das selbe Verzeichnis wie i586-pc-JIDDEROS-gcc.exe kopiert, und das natürlich in die PATH-Variable eingetragen.
  
−
*Mein ./configure erkennt long long irgendwie nicht, welches allerdings für die Unterstützung von ELF64-Dateien notwendig ist. Ohne kompilierts auch gar nicht vernünftig. Ich hab mir deswegen die config.cache mit Wordpad gegriffen, in der Zeile ac_cv_sizeof_long_long=${ac_cv_sizeof_long_long=0} die 0 durch eine 8 ergänzt und libelf_cv_int64=${libelf_cv_int64=no} das "no" durch ein "long long" ersetzt. Dann noch mal ./configure laufen lassen, das nun leichtgläubig der config.cache glaubt. Dann kannst noch
+
*Mein ./configure erkennt long long irgendwie nicht, welches allerdings für die Unterstützung von ELF64-Dateien notwendig ist. Ohne kompilierts auch gar nicht vernünftig. Ich hab mir deswegen die config.cache mit Wordpad gegriffen, in der Zeile ''ac_cv_sizeof_long_long=${ac_cv_sizeof_long_long=0}'' die 0 durch eine 8 ergänzt und ''libelf_cv_int64=${libelf_cv_int64=no}'' das "no" durch ein "long long" ersetzt. Dann noch mal ./configure laufen lassen, das nun leichtgläubig der config.cache glaubt. Dann kannst noch