Der (Un-)Sinn von Bootstrapping

darktrym

darktrym

Fahnenträger
Bekanntlich werden die besten Threads eröffnet wenn man leicht angesäuert ist. Nun, mein Anliegen ist ein wenig merkwürdig aber worin liegt der tiefere Sinn in einem elitären Bootstrapping?
Mein Fallbeispiel, sofern ich das richtig deute, FreePascal 3.0, welches Delphi mehr oder weniger gut nachimplementiert.
Nun gibt es das nicht für NetBSD, also mal übereifrig angefangen ein Rezept dafür zu schreiben. Schnell stirbt da nämlich der Bau weil einem 2.6.4 fehlt. Also zum Verständnis, weil FreePascal als Port nicht existiert, benötigt man ein FreePascal damit es baut. Nun müsste man das runterbrechen auf eine sehr, sehr frühe Version die GPC oder GCC benötigt damit man irgendwie zu Potte kommt. Alternativ gibts ein Crosscompile(keine wirklich sinnvolle Lösung), eine Linuxversion(Port ist broken und war auch nie wirklich gepflegt und ähnlich sinnfrei) oder man lädt gleich ein Binary des Vorgänger auf Sourceforge(!) herunter.
Widerspricht das nicht dem gesunden Menschenverstand, wenn der benötigte Compiler nicht weit verbreitet ist? Genauso gut könnte man am Anfang der Kette prop. Software voraussetzen.
 
Das ist ein grundsätzliches Problem wenig verbreiteter Sprachen. Ähnlichen Ärger hat man zum Beispiel mit dem Modula3-Compiler oder in abgeschwächter Form mit dem offiziellen D-Compiler. Da der Standardcompiler einer Sprache oft in der Sprache selbst implementiert ist, braucht man einen Compiler der jeweiligen Sprache um den Compiler bauen zu können... Der gängige Ansatz ist, dass man eine Binary des Compilers nutzt, um sich einen Compiler zu bauen. Wenn man paranoid ist, kann man den Compiler noch ein weiteres Mal mit sich selbst bauen.

Die GCC macht im Standard-Build übrigens genau das. Sie baut sich mit dem Host-Compiler, anschließend mit dem gerade gebauten Compiler noch einmal. Mit diesem zweiten Compiler wird der Code ein drittes Mal übersetzt, anschließend dann geprüft ob die Binaries der zweiten und dritten Stufe gleich sind. Die dritte Stufe ist das Binary, was später installiert wird.

FreeBSD hat derzeit das Bootstrap-Problem mit Clang. Neuere Clang-Versionen nutzen C++11-Konstrukte im Code, können also nur mit einem C++11-Compiler gebaut werden. Weil aber nicht alle unterstützen FreeBSD-Versionen einen C++11-Compiler haben, gibt es in FreeBSD 10.x keine neueren Clang-Versionen als 3.4.1. Das wird sich mit FreeBSD 11.0 ändern, allerdings zu dem Preis, dass Direktupdates von älteren Versionen nicht möglich sein werden. Zumindest, solange man sich das System selbst bauen möchte.
 
Yamagi schrieb:
Das wird sich mit FreeBSD 11.0 ändern, allerdings zu dem Preis, dass Direktupdates von älteren Versionen nicht möglich sein werden. Zumindest, solange man sich das System selbst bauen möchte.
Zum Vergrößern anklicken....

Wozu baut dann jedes buildworld dann clang zweimal? Ich nutze 11-CURRENT auf amd64, und buildworld braucht seit Clang 3.5 oder 3.6 deutlich länger als vorher. AFAIK passiert da nämlich was ähnliches wie beim gcc, also sollte ein Direktupdate aus den Sourcen ja auch möglich sein.
 
Ich weiß nicht, ob das jetzt ein wenig zu OT wird oder ob es einfach an meinen Laienkenntnissen liegt. Wie kann ich mir das vorstellen? Damit ich Kompiler X übersetzen kann brauche ich Kompiler X als Binary? Wie soll das funktionieren? Wie hat das ganze mal angefangen? Henne/Ei?:confused::ugly:
 
Dann biete ich gleich neben den fpc3.0 auch den fpc2.6.4 an und benutze ihn als Abhängigkeit. Ich ignoriere alle Probleme eines fremden Hosters(Sourceforge) und baue dann mir den Build 3.0. Mal abgesehen davon, habe ich auch nicht wirklich Vertrauen darin, dass das FPC-Team in der Lage wäre, solche Exoten-OSe vernünftig zu pflegen, das Binary-Paket gibts auch nur für ausgewählte Plattformen.
Ich hab ja kein Problem damit, dass man unbedingt sich selbst übersetzen will, aber dann sollte auch der Bootstrap funktionieren und nicht etwas vorausetzen, was man höchstwahrscheinlich gar nicht hat. Welche Freude ist es das Ding dann auf andere Architekturen und Plattformen zu bringen.

PS: Ja, ist immer ein Henne-Ei-Problem aber genau deshalb nutzt man verbreitete Tools zum Bau, sprich C/C++ Compiler.
 
Und das beste der Build von 2.6.4 ist hinsichtlich der GDB-Unterstützung in der IDE broken, angeblich wegen Linker-Probleme. Genau deshalb lässt man den Kram nicht von Fremden crosscompilen.
 
goblin schrieb:
Wozu baut dann jedes buildworld dann clang zweimal? Ich nutze 11-CURRENT auf amd64, und buildworld braucht seit Clang 3.5 oder 3.6 deutlich länger als vorher. AFAIK passiert da nämlich was ähnliches wie beim gcc, also sollte ein Direktupdate aus den Sourcen ja auch möglich sein.
Zum Vergrößern anklicken....
Das liegt am Aufbau des Build-System. In der ersten Stufe wird mit den Tools vom Hostsystem alles gebaut, was zum Bauen der Welt benötigt wird. Das sind make, install und eben auch Clang. Der Clang im Hostsystem kann den neuen Clang aber nicht bauen, da er kein C++11 kann. Also ist hier Ende. Anschließend werden die gerade gebauten Tools genutzt, um alles (also auch sie selbst) noch einmal zu bauen. Das soll sicherstellen, dass die neugebaute Welt keine Abhängigkeiten in das Host-System hat.

Nun gab es aber in den letzten Jahren durch eine immer engere Verflechtung der einzelnen Komponenten der Welt den ungesunden Trend, dass immer mehr Tools vorab gebaut werden. Das hat dazu geführt, dass selbst erstmal nebensächliche Tools wie dd doppelt durchgeraddelt werden. Bei einem Monster wie LLVM, wo immer mehr und mehr Bibliotheken doppelt gebaut werden müssen, tut das natürlich ganz besonders weh. Bryan Drewery, der derzeit viel am Buildsystem bastelt und für 11.0 ggü. 10.3 immerhin ~30% Beschleunigung rausgeholt hat, meinte daher auf der BSDCan, dass zu 12.0 eventuell darauf hinarbeiten wird weitgehend auf das Vorabbauen von Tools zu verzichten. Da spielt auch die religiöse Frage mit hinein, ob es überhaupt einen vollwertigen Compiler im Basissystem geben sollte.
 
Yamagi schrieb:
Da spielt auch die religiöse Frage mit hinein, ob es überhaupt einen vollwertigen Compiler im Basissystem geben sollte.
Zum Vergrößern anklicken....

Ich finde FreeBSD so sexy, eben weil es self-contained ist. Schon dass bald ein Upgrade von $ALT auf ganz neu nicht mehr gehen soll, hat ein Geschmäckle. Die Buildzeiten sind mir im übrigen total egal, seit es SSDs gibt. Wir brauchen hier für die Welt 7-9 Minuten. Wer das nicht möchte, kann ja gern binäre Updates nutzen.

Rob
 
$ALT dürfte in diesem Fall aber "älter als 9.2" sein, glaube ich. Damit dürfte man leben können, weil sicher 99% aller Selbstbauer eh lange neuere Versionen nutzen dürften.
 
Moin Yamagi,

Yamagi schrieb:
FreeBSD hat derzeit das Bootstrap-Problem mit Clang. Neuere Clang-Versionen nutzen C++11-Konstrukte im Code, können also nur mit einem C++11-Compiler gebaut werden. Weil aber nicht alle unterstützen FreeBSD-Versionen einen C++11-Compiler haben, gibt es in FreeBSD 10.x keine neueren Clang-Versionen als 3.4.1. Das wird sich mit FreeBSD 11.0 ändern, allerdings zu dem Preis, dass Direktupdates von älteren Versionen nicht möglich sein werden. Zumindest, solange man sich das System selbst bauen möchte.
Zum Vergrößern anklicken....

Gedankenspiel:
Ließe sich das Problem nicht dahingehend lösen, indem folgendes macht:
1. Makefile aus Port prüft, welche Version von CLang aktuell installiert ist
2. Wenn diese Clang-Version erheblich älter ist als die aktuell in Ports vorliegende Version, dann hole Package der aktuellen Version
3. Installiere Package
4. Kompiliere mit installiertem Package die Sourcen des aktuellen CLang

Für einen solchen Vorgang müsste das CLang-Package natürlich gegen die Bibliotheken von FreeBSD 10 gelinkt sein.

Grüßle

Jürgen
 
Ich habe es gerade noch einmal nachgeschaut: Alle Versionen ab einschließlich FreeBSD 9.1 können FreeBSD 11.0 bauen. Das man den Clang in 10.x niemals aktualisiert hat, resultiert aus der Regel, dass Direktupgrades von allen unterstützten Versionen möglich sein sollen. Das schloss lange Zeit 8.4 mit ein und als es denn EOL war, war es für 10-STABLE schon zu spät... Oder wie Dimitry Andric dazu sagte "Not
everybody agrees that it is worth the trouble." In der Praxis dürfte sich nachher mit 11.0 also gar kein Problem stellen.

Was du vorschlägst, ist der "External Toolchain Support". Der ist in 11.0 enthalten. Du kannst das System mit einem Compiler auf den Ports bauen, man muss dafür nur ein paar Optionen an make übergeben. Auf den "großen" Plattformen x86, amd64 und der ARM-Familie ist das aber den Aufwand nicht wert, da die Compiler im Basissystem modern genug sind. Anders sieht es mit den Plattformen aus, die noch immer auf dem alten GCC 4.2 hängen, der uns wohl schon bald nach dem Übergang auf 12-CURRENT endgültig verlassen wird.

Aber das wird langsam leicht Offtopic. :)
 
Weil ich vermutlich gerade einen Bug gefunden hab, wie schaut's denn bei FreeBSD mit time_t auf 32Bit-Systemen aus? Der Code für NetBSD lässt den auf 32Bit stehen obwohl ab NetBSD 6.0 time_t 64Bit ist. OpenBSD müsste ähnlich sein, aber die patchen den Quellcode noch.
 
FreeBSD/i386 hat ein 32 Bit time_t. Alle anderen Plattformen, auch die 32 Bit Varianten, haben ein 64 Bit time_t.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben