[linux-l] Cross-Compiling für Win32 (was: Cygwin Lizenz)

[Volker Grabsch]

Steffen Dettmer <steffen at dett.de> schrieb:
> * Volker Grabsch wrote on Tue, Oct 07, 2008 at 01:11 +0200:
> > > > http://www.profv.de/mingw_cross_env/
> > > 
> > > (wow, da regiert der C&P Teufel aber ;))
> > 
> > Unter den Scripten, die es dafür gibt, ist es mit Abstand
> > das schlankeste. Das C&P täuscht, weil wiederholte ähnliche
> > Fallunterscheidungen auftauchen. Würde ich das in einer
> > anderen Sprache schreiben, wären das viele Funktionen, die
> > die gleichen Parameter entgegen nehmen. Wäre sowas ebenfalls
> > in deinen Augen ebenfalls C&P ?
> 
> Die Grenzen sind natürlich fliessend, aber riecht schon bisschen
> so, als ob man vielleicht source code generation in Betracht
> ziehen sollte.

Und wo wäre der praktische Nutzen? Ich sehe generell die Gefahr,
dass jede nutzlose(!) Abstraktion die Hemmschwelle erhöht, neue
Libraries zu ergänzen bzw. alte zu fixen.

Das spricht natürlich nicht gegen sinnvolle(!) Abstraktionen,
und auch solche sind im Script eingebaut. Zum Beispiel ist die
Option "--help" so implementiert, dass das Script seinen ersten
Kommentar-Absatz herausparsed und ausgibt. Ganz wenig awk/sed-
Code, der viel doppelte Schreibarbeit erspart.

> > Würde ich das auslagern, hätte ich
> > allgemeinere Funktionen, die aber viele, viele Parameter
> > bräuchten, und deren Aufruf damit noch schwerer zu verstehen
> > wäre, als eine simple Abfolge von "tar", "./configure", "make".
> 
> ja, lesbar ist das so auf jeden Fall am besten, einfach ist eben
> einfach, stimmt. Aber den Kram jeweils in /tmp/$NEW zu bauen und
> das dann zu leeren, so ähnlich die RPM das macht, ginge das
> nicht?

Aber genau das tut mein Script doch. Nur nicht in /tmp, sondern
in "./src/paketname-xxx/". Dort wird das Paket entpackt, gebaut,
nach "./usr" installiert und dann der Ordner "./src/paketname-xxx"
wieder gelöscht.

BTW, solche Dinge sollten generell nicht in /tmp stattfinden,
weil das ein hart codierter Pfad ist, und zudem auf vielen Systemen
nicht für 200-400 MB große temporäre Datenmengen ausgelegt ist.
Oft ist es eine Ramdisk, deren Größe auf 16MB oder 64MB beschränkt
ist.

Nein, meine Cross-Umgebung soll in ihrem eigenen Verzeichnis
bleiben, so habe ich es designt. Dann erlebt man auch keine
bösen Überraschungen. Wer sein Zeug in /tmp bauen will, der
kann mein Mingw-Cross-Env einfach von vornherein nach /tmp
entpacken, oder den entsprechenden Pfad im Script anpassen
(es braucht nur eine einzige Zeile angepasst zu werden).

> > Gute Lesbarkeit, Verständlichkeit und Anpassbarkeit waren meine
> > Hauptkriterien für das Script. So kann man jedes "Build-Rezept"
> > isoliert verstehen und direkt an der Kommandozeile ausprobieren.
> 
> Ja, das stimmt. Bei den vielen Builds kriegt man kaum noch (ohne
> Probieren) raus, was das make am Ende macht...

Eben, und gerade beim Compilieren für Win32 ist das nochmals
extremer. Da gibt es viel mehr Ärger als z.B. beim Compilieren
für andere Unixe wie MacOS-X oder Solaris.

Da muss öfters mal im ./configure-Script etwas angepasst werden,
wenn z.B. Wine die Crosscompiling-Erkennung stört, weil cross-
compilierte Binaries (*.exe-Dateien) plötzlich ausführbar sind.

Wie auch immer, das ist ein Thema für sich. Der Punkt ist einfach,
dass die Shell mit ihren Standard-Unix-Befehlen genau so viel
Abstraktion mitbringt, wie ich brauche. Ich habe einige Hilfs-Aliase
versucht, aber die waren letztendlich immer nur lästig, weil man
am Ende doch wieder Hand anlegen muss, und dann ist es einfacher,
wenn alles explizit da steht.

> > * Man sollte es unter einer bash in MinGW+MSYS laufen lassen können.
> >   Gut, bei einigen Libraries wird das schwierig, wenn sie Python oder
> >   Perl zum Bauen brauchen, aber die meisten machen da keinen Ärger.
> >   Unter Linux nimmt man dann keinen Crosscompiler, sondern Wine.
> >   Vorteil: Mein Script wäre um einiges einfacher und es wären weniger
> >   Patches nötig. Nachteil: Das Script würde dann auch unter Windows
> >   laufen, und damit Druck von den Entwicklern nehmen, sich ein Linux
> >   oder *BSD zuzulegen.
> 
> Versteh nicht, warum WINE einfacher sein soll, als crosscompiler?
> Weil die configures so buggy sind? Das würde mich nicht wundern,
> denn autoconf ist echt Hammerkompliziert...

Nein, Autoconf ist gar nicht mal das Problem, im Gegenteil: Die
komplizierten Mechanismen im erzeugten ./configure-Script sorgen
gerade dafür, dass Crosscompiling-Umgebungen automatisch erkannt
werden und bestimmte Checks, die beim Crosscompiling eh nicht
laufen würden, ausgelassen werden.

Nein, Ärger bereitet es, wenn die Leute z.B. Code-Generatoren
einsetzen, die nicht in einer Scriptsprache geschrieben sind.
Diese müssen dann mit dem nativen Compiler, nicht dem Crosscompiler
übersetzt werden. Autoconf und Automake stellen hierzu hervorragende
Konzepte und Mechanismen zur Verfügung, aber wenn ein Paket-Maintainer
diese nicht nutzt ...

Noch häufiger tritt jedoch das Problem auf, dass die Leute per
Hand irgendwelchen unsauberen Shell-Code in ihre configure.ac
hinein schreiben, der dann beim Crosscompiling nach hinten los
geht. Der Klassiker, über den ich zigmal gestolpert bin, ist
ein Anruf von "uname", und je nach System werden bestimmte Linux-,
BSD- oder Windows-Libraries aktiviert. Beim Windows-Crosscompiling
liefert "uname" dann Linux, wodurch genau die falschen Hooks aktiviert
werden. Dieser Quatsch lässt sich zum Glück mit einem kurzen sed-
Befehl lösen.

Hinzu kommt das bereits erwähnte Problem, dass Wine unter Umständen
die Crosscompiling-Erkennung von ./configure aushebelt. Auch das
kann man aber mit einem einzelnen 'sed'-Aufruf beheben.

Auch ärgerlich sind Projekte, die kein Autoconf benutzen, sondern
"einfache" Makefiles. Das ist zwar generell eine super Sache, ein
handgeschriebenes Makefile ist für einfache Projekte viel einfacher
zu verstehen und anzupassen. Aber wenn es nicht sauber geschrieben
ist, und z.B. "ar" statt "$(AR)" aufruft, wird's ätzend. Dann kann
ich nämlich nicht einfach

    make AR="i386-mingw32msvc-ar" CC="..." ...

schreiben, sondern muss das Makefile erstmal patchen. Es gibt aber
auch Positiv-Beispiele. Erfahrene Leute führen in ihren Makefiles
einen "CROSS"-Prefix ein, das sieht etwa so aus:

    CROSS=

    CC=$(CROSS)cc
    AR=$(CROSS)ar
    LD=$(CROSS)ld
    STRIP=$(CROSS)strip
    ...

Dann genügt ein einfaches:

    make CROSS=i386-mingw32msvc-"

und es werden durchweg die Cross-Tools benutzt.

Aber der Punkt ist, dass egal ob Autoconf, Automake oder einfaches
Makefile immer besondere Aufmerksamkeit der Paket-Maintainer gefordert
ist. Und wenn der Maintainer sein Paket niemals praktisch crosscompiliert
hat, wird er dabei irgendwelche Fehler machen und nicht entdecken. Zwar
kann man als Außenstehender entsprechende Bugfixes beisteuern, aber ein
paar Versionen später könnte es wieder an anderer Stelle haken. Es ist
einfach eine zusätzliche Anforderung an die Pakete, die beim nativen
Compilieren komplett entfällt.

Diese Argumentation trifft selbst dann zu, wenn man für Embedded-Devices
programmiert. Dann hat man kein bequemes Wine, sondern muss qemu und
Konsorten heran ziehen. Dennoch ist dieser zusätzliche Ärger konstant,
er wächst bei steigender Paketanzahl eben _nicht_ mit!

Rob Landley hat zu dem Themen einen exzelleten Artikel geschrieben:

    http://landley.net/writing/docs/cross-compiling.html

Ich hatte mit ihm ein sehr interessantes Gespräch per E-Mail, durch
das er mich auf die Idee mit MSYS+Wine brachte.

> > Was den letzten Punkt angeht: Ich bin mir ohnehin nicht sicher,
> > ob dieses Script der freien Software - politisch gesehen - mehr
> > nützt oder mehr schadet. Ich muss einfach darauf vertrauen, dass
> > die Entwickler es nur zum Crosscompilieren von Tools verwenden,
> > die es sowieso schon in anderer Form für Windows gibt. Ich habe
> > auch schon den Support für eine der Libraries (libowfat) auf Wunsch
> > des Library-Autors (Fefe) wieder heraus geworfen.
> > 
> > BTW, wenn es nach Eric S. Raymond geht, ist das Script so lange in
> > Ordnung, wie es keine Win64-Architektur unterstützt. ;-)
> > (http://catb.org/esr/writings/world-domination/world-domination-201.html)
> 
> wieso, lass die Leute doch Win nehmen und Blueray mit Blut
> bezahlen, wenn sie denn müssen. Maximal kommt am Ende eine
> natürliche Auslese.

Die sog. "natürliche Auslese" ist nur dann fair, wenn der Markt
gesund ist, und nicht durch zusätzliche Strukturen (Monopole,
Erpressung, etc.) verzerrt wird.

Wieso hat sich Win95 durchgesetzt, obwohl das damalige MacOS
eher auf dem Markt _und_ besser war? Und was ist mit OS/2 und
Konsorten? Sicher, Microsoft durfte für seine illegalen (genauer:
verbrecherischen) Methoden ordentlich Zaster an Apple abdrücken,
aber die Marktanteile hatte Microsoft dennoch, und die sind viel
mehr wert als jede Abfindungszahlung.

Man kann eigentlich noch weiter zurück gehen: Wenn deine Argumen-
tation stimmen würde, hätte es schon Windows 3.1 nicht mehr
geben dürfen, ja nicht einmal MS-DOS 6.0. Aber gab es eine
"natürliche Auslese" der MS-DOS-Nutzer? Damals gab es weit
überlegendere DOS-Systeme wie NW-DOS.

Nein, wenn Windows vom Markt verschwindet dann nicht, weil die
Konkurrenz großartige Produkte hervorbringt. Denn das tut sie
schon die ganze Zeit über, ohne das Quasimonopol von MS auch
nur anzukratzen. Nein, wenn Windows verschwindet, dann nur durch
richtig, richtig grobe Fehler seitens Microsofts. So groß, dass
selbst ihre üblichen illegalen Machenschaften (siehe EU-Prozess
gegen Microsoft) diesen Fehler nicht mehr wett machen können.

Vista ist vielleicht solch eine Panne. Oder die Portierung auf
64-Bit-Systeme. Wer weiß. Aber wenn es soweit ist, dann wird
Microsoft auf jede noch kleine (moralische) Unterstützung
angewiesen sein ... und mein mingw_cross_env könnte solch eine
Unterstützung darstellen. Daher meine moralischen Bedenken.

Auch die bekannte Argumentation von Fefe geht in diese Richtung:
http://www.fefe.de/nowindows/

> > Ansonsten: Ja, SDL unter Windows nutzt natürlich die win32-API,
> > genauso wie es unter Linux die X11-API nutzt.
> 
> Ich würde mal raten, dass man SDL auch mit CL.EXE bauen kann (und
> anderen).

Keine Ahnung. Aber wenn du es ausprobieren möchtest, tu dir
keinen Zwang an. Das Ergebnis würde mich auf jeden Fall
interessieren!

> > und die "Emulation" z.B. eines Unix-Dateisystems
> > geht meistens nach hinten los. Zum Beispiel ist es ätzend,
> > dass man dem (mit Cygwin gebauten) Rsync unter Windows keine
> > Windows-Pfade "C:\..." übergeben kann.
> [...]
> Gibts eigentlich inzwischen rsync für native windows? Ohne diese
> Probleme? Hätt gern sowas für win backups.

Nein, kenne ich nicht. Deshalb habe ich vor einiger Zeit mal ne
Anleitung dafür geschrieben:

    http://wiki.njh.eu/Rsync_unter_Windows


Gruß,

    Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR