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

[Steffen Dettmer]

* Volker Grabsch wrote on Mon, Oct 27, 2008 at 23:30 +0100:
> > 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.

Der praktische Nutzen von source code generation wäre natürlich,
Redundanz zu vermeiden. Natürlich hat das diverse Nachteile. Auch
nützliche Abstraktionen erhöhen Hemmschwellen (ich würde sagen:
Hürden) und können die Lesbarkeit erschweren, klar, wäre ja sonst
zu einfach :)

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

Weiss gar nicht mehr, was ich da eigentlich meinte.
Es muss aber nicht unbedingt gut sein, unter src/ zu schreiben.
Aber das meinte ich mit dem ersten Kommentar jedenfalls nicht. :)

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

compiler maschine mit kleinem /tmp? Hatte ich noch nicht. Klar
sollte man das ändern können. Ich hab als /tmp gern RAID0 und
ohne Backup. Andere löschen es beim booten. Klar, muss man
gucken, was man hat und was man braucht. In einer Ramdisk zu
bauen bringt unter Linux (eines sehr einfachen Tests nach) nicht
so viel, weil das caching sehr gut funktioniert (und bei vollem
RAM nur langsamer wird, aber immernoch geht :)).

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

ja, wenn so eine Anpassung so leicht möglich ist, kann man nicht
meckern, prima.

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

Mit mingw unter linux geht das ja noch. Aber mit automake via
cygwin und CL.EXE wirds schnell nervig, beispielsweise, dass
leider keine symlinks mehr funktionieren und so.

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

Was stört? Was ich Crosscompiling-Erkennung? Bei autoconf wenn
man --host angibt, oder?

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

Ja, soweit die Theorie...

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

Ja, sowas lässt sich im Einzelfall dann jeweils schnell lösen,
aber es allgemein und richtig zu machen, wird schnell ein
Problem. Und es gibt überall Grenzen. Eigentlich macht das
autoconf/automake viele Annahmen. Wenn die nich passen, wirds
schnell nervig, z.B. wenn man einen Kompiler verwenden will, der
keine binaries erzeugen kann oder seine ANSI-C header selbst
mitbringt usw.

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

Nein, das geht genau für'n gcc, am besten noch mit --host
irgendwas-linux. Da ist die Welt natürlich einfach. Automake
nimmt zum linken ja dann auch u.U. $(CC) oder gar $(CXX) (was
möglicherweise aber nur ein automake 1.6.3 bug ist), was die
Platform/Toolchain so aber vielleicht gar nicht kann. Wobei
autoconf ja die jeweiligen Tests auslässt, wenn man CC von aussen
setzt.

Vielleicht sollte man u.A. daher immer noch was ums configure
rumwickeln. Andererseits möchte man eigentlich ja auch lieber
nicht...

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

Na klar, das muss man ständig testen. Ich gebe mir z.B. als
Paket-Maintainer viel Mühe, aber irgendwo hab ich dann doch nicht
gebaut, z.B. unter cygwin (weil das ja so lahm ist) und natürlich
gibts dann mindestens ein Detail, was zum Abbruch führt. Oder man
stoplert plötzlich darüber, dass das MSYS `gawk' so dermassen
uralt ist, dass es kein hex kann :)

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

Verstehe den Zusammenhang nicht? Ich kompiliere viel für
Embedded-Devices über Wine (autoconf/automake + WINE ist immer
noch viel schneller als cygwin + autoconf/automake).

> Dennoch ist dieser zusätzliche Ärger konstant,
> er wächst bei steigender Paketanzahl eben _nicht_ mit!

Na ja, sagen wir mal, er skaliert freundlich (bisschen wächst es
schon, weil eine Spezialität gibts ja doch immer :)).

> Rob Landley hat zu dem Themen einen exzelleten Artikel geschrieben:
> 
>     http://landley.net/writing/docs/cross-compiling.html

mmm... Klingt irgendwie ziemlich linux+gcc spezialisiert. Die
Erklärung `Host vs Target' finde ich unglücklich, weil es die
gcc/autoconf Begriffe verwendet, aber irreführend (da gibts ja
build für den Compiler, host für die Platform, auf der das
kompilierte läuft [was auch wieder ein Compiler sein kann, aber
nicht muss] und das target, was im Falle des kompilierens eines
Compilers die Platform ist, für die der kompilierte Compiler auf
host eine Ausgabe erzeugt). Meist hat man --host ja genau für
das, was man nicht target nennen darf, weil das die Leute
verwirrt :)
(das macht eigentlich das autoconf unglücklich, aber schwer daran
 vorbeizukommen)

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

`fair' ist immer sehr relativ. Hier wäre mir Fairness eher egal,
aber auch die Leute, die kein Win/Blueray nehmen, müssen darunter
leiden (beispielsweise, weil es wegen geringer Nachfrage gar
keine DVDs mehr gibt oder so). Das gilt allgemeiner.

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

Für etliche schlipstragende Manager ist Microsoft eben besser
gewesen und immernoch besser. Finde, dass liegt nicht (nur) an
Microsoft, sondern an den jeweiligen Managern und so weiter.

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

Die `natürliche Auslese' ist nur anders. Früher, unter MS-DOS 6.0
z.B., gabs viele, die sich auskannten. Da hat irgendwie jeder
zweite was in BASIC gemacht usw. Unter Win waren es weniger und
wohl noch weniger auf'm Mac. Da kann sich dann ein gcc oder ein
autoconf leisten, diese (Win) Platform einfach mal nicht zu
unterstüzten (mingw ist ja 3rd party). Sieht man IMHO auch am
Admin-Durchschnitt. Von einem klassischem Unix-Guru hat man wohl
eher wenig mitbekommen, weil man die Störungen gar nicht bemerkt
hat, alles remote und schnell und so korrigiert wurde. Winadmins
sind im Allgemeinen überall in den Firmen gut bekannt (weil man
sich so oft sieht).

Wenn denn die Leute jetzt blueray kaufenkaufenkaufen, gibts nur
noch blueray und die, die das nicht kaufen, merken irgendwann von
den `anderen' einfach nichts mehr - und gut ist. Vielleicht
profitieren dann die lokalen Künstler, weil man ins Theater geht
oder sich plötzlich Leute in ganz kleinen Kinos die Filme `aus
der Umgebung' anschaut, die mehr mit Geist als mit Geld
produziert wurden.

   (die Hoffnung stirbt zuletzt :))

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

Warum soll Win denn verschwinden? Oder andere Playstations? Ist
doch gut, wenn's sowas gibt; man stelle sich vor, die ganzen
Winuser würden sonst Linux einsetzen. Also, DIE User (nicht die
interessierten, sondern die `mir doch egal' - ich nutze Win und
Linux viel). Die Server von MS sind auch schön teuer, da müssen
die Entscheider wenigstens indirekt leiden. Leider müssen da alle
drunter leiden. Muss man positiv sehen: man selbst weiss
wenigstens, warum. Um die indirekte Strafe zu vollstrecken, nimmt
man gern kleine Nachteile in Kauf. Die grösste Strafe ist am Ende
ja das Produkt, in dem Fall, dass die blueray Käufer dann ständig
blöde Hollywoodfilme gucken müssen.

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

Sowas finde ich meistens ein bisschen albern. Besonders sowas wie
`completely free platform' und dann auf einem PC arbeiten, was???
FSF/GNU fing im Prinzip ja auch so an, wie bei cygwin kritisiert.
Überhaupt, bloss weil etwas Geld kostet, gibts gleich keine
Freiheit? Na ja, die Diskussionen hatten wir ja schon häufig.

Klar, man kann darum bitten und seine Meinung haben und anderer
sollten vielleicht überlegen, dass zu respektieren, natürlich.

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

Laut FAQ gehts:
SDL can be built with Visual C++, Borland C++, Cygwin, MinGW,
Dev-C++, and Watcom C++.

schon eine beeindruckende Liste. Geht aber sicherlich nicht alles
via autoconf ;)

> Nein, kenne ich nicht. Deshalb habe ich vor einiger Zeit mal ne
> Anleitung dafür geschrieben:
> 
>     http://wiki.njh.eu/Rsync_unter_Windows

/cygdrive/x/ muss man sich dann aber auch erst mounten, oder?

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.