F
@VLSI_Akiko sagte in Vector von Iteratoren in Template:
Allerdings muss ich gestehen, dass ich nicht wirklich weiß, wie das unter Windows aussieht. Ich meine schon allein dass GCCs Buildsystem auf den automake Tools basiert, dürfte für Windows die Hölle sein.
Daher auch der Docker-Container, in dem ein Debian 11 installiert wird und dann GCC+MinGW für Windows als Canadian Cross gebaut werden. Meine vorherigen GCC habe ich tatsächlich noch unter Windows mit MSYS2 gebaut. Das geht tatsächlich mit erstaunlich wenig Macken, die durch das Build-Setup zutage treten.
Windows hat aber ein extrem grosses Problem, wenn es um solche Builds geht: Das System ist arschlahm im Umgang mit vielen kleinen Dateien und beim Erstellen neuer Prozesse - das sind genau die Dinge, die man für solche Builds benötigt. Dass sich der Echtzeitschutz des Windows Defender immer nach ner Weile wieder einschaltet und dann anfängt, jede böse .o-Datei zu scannen macht die Sache auch nicht wirklich besser. Du würdest wahrscheinlich vom Glauben abfallen, wenn du sehen würdest, wie sich Windows allein durch so ein configure-Skript quält. In der Zeit hat der Docker-Container den GCC schon fast fertig gebaut
Das ist letztendlich auch der Grund warum ich die Mühe mit dem Canadian Cross auf mich genommen hab, der ja nochmal ne Ecke fummeliger ist. Jetzt kann ich sogar -O3 -flto und wegen dem Canadian alles doppelt bauen (einmal für Linux-"build" und einmal für Windows-"host") und bin trotzdem schneller fertig als vorher^^
Edit:
@VLSI_Akiko sagte in Vector von Iteratoren in Template:
Ich bin ehemaliger Distributionsbauer (SuSE) und betreibe bis heute Integration mit Yocto, OpenADK, buildroot, crosstool-ng und gelegentlich auch mit meinen eigenen cross toolchain Scripten um neue Features zu testen oder eben weil ich eine Toolchain komplett basierend auf MUSL brauche (Statisch linken mit MUSL erzeugt einfach deutlich kleinere Binaries.) Öhm, also ja, es ist Bestandteil meines Jobs.
Das ist auf jeden Fall interessant. Mit buildroot kam ich via OpenWRT in Berührung als ich mir mal nen Firmware Image und ein extra Paket für meinen Router gebaut habe. Das habe ich letztendlich auch in einem Docker-Container gemacht. Der OpenWRT-Buildprozess ist da schon etwas pingelig bezüüglich des Build-Systems gewesen. WSL2 und Alpine Linux mochte der der nicht wirklich. Daher einen Debian-Container genommen für den Build. Die kann man schön per Skript nur für den Build aufsetzen und dann wieder wegwerfen. Für Server-Deinste und sowas setze Docker nicht ein, aber für sowas finde ich das genau richtig.
Und crosstool-ng? Kann das nicht eh schon sowas wie nen MinGW für Windows bauen? Hab mir das nie wirlich angesehen ... oder ist das nur um Crosscompiler für die native Maschine zu bauen?
Dass du Musl erwähnst find ich auch witzig. Das ist einer der Gründe, weshalb das bei meinem Build dabei ist. Ich hätte gerne für Windows nen Compiler für generische Linux-Targets zu Testen. Da hat sich Musl als libc angeboten, da kann man einfach mal ne statisch gelinkte Binary auf den Linux-Rechner schieben um sie dort zu testen und habe letztendlich nur eine Abhängigkeit vom Linux-Kernel.