GNU Toolchain selber bauen

[MrScoville]

Hallo,

bekanntermaßen ist der GNU Toolchain in den stable Releases eher alt. Gibt es ein Kochrezept, wie man ihn aus den Sourcen neu bauen sollte?

Also, wenn der Toolchain in der Version nach der Installation von z.B. Debian 8.7 installiert ist...
1. Welche Sourcen muss man herunter laden, um ihn auf den aktuellen Stand zu bringen?
1a. Auch das Drumherum, M4 z.B., manche Tests der Tools hätten gerne FLEX und BISON, usw...
2. Mit welchen Sourcen fängt man an, die neuen Versionen zu bauen?
3. Welche Tools muss man zwischendurch nochmals bauen, wenn andere Tools vorher schon gebaut worden sind? Also, wo gibt es Abhängigkeiten zwischen den Versionen?
4. Welches weitere Drumherum sollte man dann danach neu bauen? glibc? Gleich den ganzen Kernel?

Ich möchte einfach eine aktuelle Version des GNU Toolchains haben, nicht gleich ein ganz neues System. Und gibt es da auch was von Ratiopharm, also halt ich rufe ein Skript auf, und das tut das ganze Zeug von selber? Ich bin doch bestimmt nicht der erste mit dem Wunsch? Ein Eintrag für die Apt-Tools reicht mir natürlich mehr als genug.

Nochmals: Ich will kein neues Linux bauen, sondern das System nur hinsichtlich des GNU Toolchains auf den neuesten Stand bringen.

Mein System:
Linux kilo 3.16.0-4-amd64 #1 SMP Debian 3.16.43-2 (2017-04-30) x86_64 GNU/Linux

[breakthewall]

4. Welches weitere Drumherum sollte man dann danach neu bauen? glibc? Gleich den ganzen Kernel?

Wie wäre es mit der nahezu ganzen Distribution?

Das ist nicht so einfach wie dir das vorstellst. Ein GNU/Linux ist ein Gesamtkonzept was aufeinander abgestimmt ist. Derart essentielle Bestandteile zu verändern, sorgt automatisch für Inkompatibilitäten und massive Abhängigkeitsprobleme, zumal die Paketbasis von genau dieser Toolchain abhängt. Nur mal angenommen, es würde sich in der Toolchain etwas Essentielles verändern, oder gar ausgemustert werden. Was passiert dann mit installierten Paketen, die voraussetzen diese Bedingungen vorzufinden? Ich würde Dir raten schlicht auf Debian-Testing oder Debian-Unstable umzusteigen, wenn aktuelle Pakete wichtig sind, zumal zwangsweise alles aktualisieren musst um die Kompatibilität zu wahren.

Nochmals: Ich will kein neues Linux bauen, sondern das System nur hinsichtlich des GNU Toolchains auf den neuesten Stand bringen.

Du fährst bedeutend besser wenn alles aktualisierst. Und nebenbei kann man ja noch erwähnen, dass Debian 9 kurz vor Release steht, womit in Kürze unmittelbar upgraden könntest. Allerdings könntest das auch sofort, indem in der sources.list alle Einträge namens jessie in stretch abänderst. Das ist der Codename für Debian 9. Im Anschluss folgt ein apt update && apt full-upgrade und die Sache wäre erledigt. Und hinsichtlich der Stabilität muss man sich auch keine Sorgen machen, da Debian 9 schon seit Monaten sauber läuft.

[MrScoville]

Wie wäre es mit der nahezu ganzen Distribution?

Das ist nicht so einfach wie dir das vorstellst.

Nochmals: Ich will kein neues Linux bauen, sondern das System nur hinsichtlich des GNU Toolchains auf den neuesten Stand bringen.

Du fährst bedeutend besser wenn alles aktualisierst. Und nebenbei kann man ja noch erwähnen, dass Debian 9 kurz vor Release steht, womit in Kürze unmittelbar upgraden könntest.

Was frage ich bloß...
Ich fahre besser wenn ich alles aktualisiere... Genau WAS alles? Und wie? Oder einfach dem Debian-Orden glauben und folgen? oO Im Ernst... Ich habe eine einfache Frage gestellt, und die Antwort artet darin aus, dass meine Frage schon falsch war oder unangebracht oder unziemlich... wie konnte ich es wagen?!

[DeletedUserReAsG]

Ach, mal wieder am Trollen? Antwort korrekt, freundlich, höflich, aber sachlich nicht genehm, also wird wieder wild beleidigt? Was soll an „das ist technisch höchst problematisch und wird wahrscheinlich nicht umsetzbar sein – besser ist’s, das ganze System auf den adäquaten Stand zu bringen“ rechts sein? Lächerlich

Edit: offensichtlich muss man die Beiträge dieses Users „for teh truth“ quoten, sonst wird da lustig drin umhereditiert und der Kontext geht verloren … :-/

[MrScoville]

Ach, mal wieder am Trollen? Antwort korrekt, freundlich, höflich, aber sachlich nicht genehm, also wird wieder wild beleidigt? Was soll an „das ist technisch höchst problematisch und wird wahrscheinlich nicht umsetzbar sein – besser ist’s, das ganze System auf den adäquaten Stand zu bringen“ rechts sein? Lächerlich.

Am trollen... Also, wenn ich frage, wie ich die GNU Toolchain auf den aktuellen Stand bringen kann, die Antwort der Debian-Community im Groben und Ganzen ist "oh, das ist knifflig, lass das lieber" und ich mich dann beklage, dass es einfach nicht voran geht, bin ich ein Troll? Okay, dann bin ich gerne ein Troll.

Im Ernst, wenn es zwischen "stable" und "testing" etwas für Menschen gäbe, die nicht auf Steinzeit-Niveau stehen wollen und zugleich nicht ständig crashes haben möchten... Ja, ist zuviel verlangt, richtig? Also solange nicht dein Name in den Meriten steht... gosh...

Ich ergänze einfach mal... Während viele. viele, viele Software, etwa der gesamte GNU Toolchain sich inzwischen getestet (!) auf Versionen einpegelt, die von anderen Sourcen bereits verlangt werden, haben hier im Forum und anderswo manche Leute nichts besseres zu tun als... wie nennt man das eigentlich, wenn Menschen ihre eigene schlechte Befindlichkeit auf andere abwälzen und diese anderen schuldig erklären?

Schöner wäre es, Debian würde z.B. mal gcc 4.9.x auf gcc 6 aufholen, aus guten Gründen.

[DeletedUserReAsG]

Also, wenn ich frage, wie ich die GNU Toolchain auf den aktuellen Stand bringen kann, die Antwort der Debian-Community im Groben und Ganzen ist "oh, das ist knifflig, lass das lieber" und ich mich dann beklage, dass es einfach nicht voran geht, bin ich ein Troll?

Nein, du bist ’n Troll, wenn du Leute, die dir die Schwierigkeiten deines Vorhabens erläutern und sinnvolle Alternativen aufzeigen, implizit als Nazis beschimpfst.

Im Ernst, wenn es […] etwas für Menschen gäbe, die nicht auf Steinzeit-Niveau stehen wollen und zugleich nicht ständig crashes haben möchten.

So, Testing crasht ständig? Weißt du überhaupt ansatzweise, wie die Sachen so zusammenhängen, in welchem Status Testing gerade ist? Offensichtlich nicht. Ich würde ja schreiben „informiere dich, oder probier’s mal aus“, aber das wäre Imperativ, und der wird ja nur von Nazis benutzt, right?

[MrScoville]

So, und jetzt mal wieder zurück zum Thema... Wie bekomme ich den GNU Toolchain auf alles hoch, was den gcc --version = 6 bringt? Samt Drumrum, binutils, automake etc etc... Manche wollen hier nur meckern, vielleicht gibt es ja doch auch Antworten mit Sinn und Verstand

[MrScoville]

Nein, du bist ’n Troll, wenn du Leute, die dir die Schwierigkeiten deines Vorhabens erläutern und sinnvolle Alternativen aufzeigen, implizit als Nazis beschimpfst.

Zum echt letzten Mal... Dass die Sache kein Schwuppsdiwuppst, mal eben runter laden und ./configure && make && make install ist, ist mir schon klar. Wäre es das, hätte ich nicht gefragt, hm? Das hätte ich schon selber hinbekommen.

Deine Antworten waren allerdings "lass es, du bist zu doof, wir wissen es besser, punkt." Was mich begeistert hätte, wäre "lass es, das ist schwierig, aber wenn du unbedingt willst, dann erstens, zweitens, drittens, viertens... probier es aus, klappt auf Anhieb sicher nicht, frag mich oder frag x@y.z oder schau mal im Forum u.v.w. Aber nein, von dir kam nur "du bist zu dumm, um das zu schaffen, ich bin viel cooler, lass das, mach es so, wie ICH es dir sage!" Merkst du was? Nein, eh nicht.

[DeletedUserReAsG]

Aber nein, von dir kam nur "du bist zu dumm, um das zu schaffen, ich bin viel cooler, lass das, mach es so, wie ICH es dir sage!"

Das ist deine Interpretation, und die ist schlicht falsch. Aber das kennt man ja schon von dir – jede Antwort, die dir nicht passt, ist ’n Angriff auf dich, und alle, die dir helfen wollen, sind eh nur blöde, wenn sie nicht genau die erhoffte Antwort bringen, wie ’ne Suchmaschine, sondern das Vorhaben hinterfragen.

Der Punkt ist: du zerschießt dir dein System, wenn du zentrale Komponenten austauscht, und den Rest, der auf den ursprünglichen Versionen basiert, nicht. Möglichkeiten wären ein Verzeichnis außerhalb der Systempfade, besser ein chroot, oder ’n Container (z.B. nspawn), damit man mit den Umgebungsvariablen keine Probleme bekommt, wo man die gewünschten Sachen zusammenbaut, ohne dass sie das eigentliche System stören. Ist Aufwand, aber machbar – als Orientierung kann der betreffende Abschnitt aus LFS dienen.

[breakthewall]

Schöner wäre es, Debian würde z.B. mal gcc 4.9.x auf gcc 6 aufholen, aus guten Gründen.

Code: Alles auswählen

$ apt show gcc
Package: gcc
Version: 4:6.3.0-4
Priority: optional
Section: devel
Source: gcc-defaults (1.168)
Maintainer: Debian GCC Maintainers <debian-gcc@lists.debian.org>
Installed-Size: 44,0 kB
Provides: c-compiler
Depends: cpp (>= 4:6.3.0-4), gcc-6 (>= 6.3.0-9~)
Recommends: libc6-dev | libc-dev
Suggests: gcc-multilib, make, manpages-dev, autoconf, automake, libtool, flex, bison, gdb, gcc-doc
Conflicts: gcc-doc (<< 1:2.95.3)
Tag: devel::compiler, devel::lang:c, interface::commandline,
 role::metapackage, role::program, suite::gnu,
 works-with::software:source
Build-Essential: yes
Download-Size: 5.196 B
APT-Manual-Installed: yes
APT-Sources: http://ftp.de.debian.org/debian unstable/main amd64 Packages
Description: Der GNU-C-Compiler
 Dies ist der GNU-C-Compiler, ein recht portabler, optimierender C-Compiler.
 .
 Dies ist ein Abhängigkeitspaket, welches den Standard-GNU-C-Compiler zur
 Verfügung stellt.

[MrScoville]

Möglichkeiten wären ein Verzeichnis außerhalb der Systempfade, besser ein chroot, oder ’n Container (z.B. nspawn), damit man mit den Umgebungsvariablen keine Probleme bekommt, wo man die gewünschten Sachen zusammenbaut, ohne dass sie das eigentliche System stören. Ist Aufwand, aber machbar – als Orientierung kann der betreffende Abschnitt aus LFS dienen.

Container und LFS klingen jetzt aber danach, dass ich danach jenseits von Gut und Böse bzw. Debian bin, oder? Bei den "Testing" Versionen kann man mit ein bisschen Herumfuchteln in den Konfigs ja ein bisschen vorauseilen und sich dann nach und nach einholen lassen.

Ich habe halt ein paar sehr spezielle Pakete hier in der Mangel, die sich standhaft wehren, sich mit der GNU Suite 4.x bauen zu lassen. Nun kann ich mir überlegen, ob ich nur die GNU Suite levele oder mich in die Tiefen der Pakete versenke, die leider aus so viel Code bestehen, dass ich damit auch Weihnachten 2018 noch nicht fertig wäre. Als störrischer Kerl weigere ich mich einfach, ein "make install" rauszuhauen, bevor "make check" ohne Fehler durchläuft. Der Haken an der ganzen Angelegenheit ist (das habe ich ja nun doch schon rausgefunden), dass die Fehler beim "make check" weniger am Compiler, sondern an den Binutils liegen, welche dann wieder Abhängigkeiten auf die glibc haben. Nach einem zugegebenermaßen nicht allzu akribischen Blick in die Tests und deren Makefiles könnten die 4.9er-Binutils schon eigentlich funktionieren, glaube ich. Aber das Abhängigkeitsgeflecht ist so dermaßen derb wie in den schlechten, alten Zeiten, als ein "GOSUB" für den heiligen Gral der Entkopplung gehalten wurde.

Im Ernst will ich gerade eben nicht nen neuen Kernel selber bauen. Dafür hab ich viel zu wenig Ahnung.

[Colttt]

Wenn man zentrale Komponenten auswechselt, wie zum Beispiel glibc, ist man immer jenseits von Gut und Böse

Wenn du versuchst etwas zu Kompilieren und es nicht klappt, dann sag doch welches Programm und was genau die Fehler sind? Evtl kann man dir da dann helfen!

[MrScoville]

Wenn man zentrale Komponenten auswechselt, wie zum Beispiel glibc, ist man immer jenseits von Gut und Böse

Wo du Recht hast, hast du Recht...

Also. eigentlich geht es um das Hochziehen einer Minibian-Version ohne systemd. Oh, das böse Wort... Keine Sorge, Fanboy bin ich zwar immer noch nicht, aber ich habe mich an systemd gewöhnt. Hat halt seine Vor- und Nachteile. Aber auf nem Raspberry braucht es jeden einzelnen Taktzyklus, und ich brauche ein paar ganz spezifische Kerneltreiber für Hardware, die am GPIO und an nem USB-Port hängt, und ich brauche eine Erweiterung von Qt5, die sich eben nicht mit 4.9 übersetzen lässt, sondern erst mit 5.x, und eine Alpha-Version, die ich vom Entwickler habe, sogar nur mit 7.x.

So, und das Ganze dann auch noch als Cross-Compiler-Suite für die Klitsche hier.

Custom Kernels für die Raspberrys zu bauen, ist schon okay, laufen auch prima, das ganze Cross-Compiler-Gedöns und Sourcen und Header und libs sind jetzt kein Hexenwerk. Der Entwickler der Hardware meinte jedoch, ich könnte mich entweder durch alle Feinheiten von systemd hangeln und alles abschalten, was geht, oder ich gehe auf seine Version von Init zurück. Nach einem Blick in seinen Init-Code bin ich doch eher überzeugt von dieser Lösung, das ist schon fast ein "MicroBian". 5 Runlevel ("autonomous", "interactive", "powerfail", "shutdown", "reboot"), und alles, was beim Booten zusätzlich gestartet werden soll als Daemons, steht in genau einer Datei, die seriell abgearbeitet wird. Und nun ist seine Hardware bzw. der Treiber dazu aufgrund von arg vielen Rechenoperationen (die schon den Grafik-Chip behelligen) SEHR hungrig, wenn man sehr schnell sehr präzise Reaktionen haben will.

Die Sache ist, mit viel Frickelei könnte ich auch ein anderes Board benutzen, das wäre dann aber mal entspannte 150 Euro teurer (FPGA-basiert) und Jahre von einer eigenen Lösung entfernt. Der besagte Hardware- und Treiber-Entwickler ist aber aufgrund seiner Situation nicht willens, kostenlosen Support zu liefern, schon gar nicht für jemanden wie mich, der keine kommerziellen Interessen verfolgt.

Also, was ich mir vorstellen könnte, ist, in nem Docker oder gleich in einer VM ein komplett eigenes System hochzuziehen. Dann scheint es mir nach meinen Versuchen, wegen denen ich hier ja überhaupt so jammere, aber von der aktuell offiziellen Debian 8 bis zum "State of the art" ein sehr dorniger Weg zu sein.

Woran ich regelmäßg scheitere, ist, die entsprechend neue libc zu übersetzen und dann zu installieren, ohne dass mir die ganze Umgebung mit nem core-dump um die Ohren fliegt. Ich schätze, ich scheitere irgendwie an der korrekten Reihenfolge. Irgendwie müsste ich die libc wohl erst bauen und irgendwo parken, dann alles, was von ihr abhängt, genau gegen diese libc neu bauen, alles eben nicht installieren... und dann? Am Ende lande ich bei einem eigenen ISO? oO

[DeletedUserReAsG]

Warum nimmst du nicht einfach ein System, das deinen Ansprüchen bereits genügt? Das Einarbeiten in ein Solches ist garantiert weniger Aufwand, als grundlegende Libs eines gegebenen Systems auszuwechseln und alles andere dafür neu zu bauen – wodurch man am Ende (wenn man da je hinkommt) eh ein unwartbares Etwas hätte, das man nicht mal mehr gescheit updaten könnte.

[Meillo]

Warum nimmst du nicht einfach ein System, das deinen Ansprüchen bereits genügt? Das Einarbeiten in ein Solches ist garantiert weniger Aufwand, als grundlegende Libs eines gegebenen Systems auszuwechseln und alles andere dafür neu zu bauen – wodurch man am Ende (wenn man da je hinkommt) eh ein unwartbares Etwas hätte, das man nicht mal mehr gescheit updaten könnte.

Vielleicht will er richtig was lernen. In dem Fall sollte er bei uns mit solchen Fragen willkommen sein.

Natuerlich kann man ihm dann auch LFS empfehlen ... aber bringt es einen nicht ueblicherweise am meisten weiter wenn man seine abgefahrenen Ideen einfach mal umsetzt?! Das Ergebnis ist in diesen Faellen meist egal.

[DeletedUserReAsG]

Ich zitiere aus dem Eingangsbeitrag:

Nochmals: Ich will kein neues Linux bauen, sondern das System nur hinsichtlich des GNU Toolchains auf den neuesten Stand bringen.

Das Auswechseln der libc läuft aber genau darauf hinaus. Deswegen mein Vorschlag mit dem chroot, oder, problemärmer, mit dem Container. Oder zumindest in einen eigenen Verzeichnisbaum.

[…] bringt es einen nicht ueblicherweise am meisten weiter wenn man seine abgefahrenen Ideen einfach mal umsetzt?! Das Ergebnis ist in diesen Faellen meist egal.

Soweit ich das bisher verstanden habe, liegt der Idee eher der Wunsch zugrunde, fremde Software bauen zu können; weniger der Wunsch, sich in die Interna einzuarbeiten. Das Ergebnis wäre in diesem Fall nicht egal.

[owl102]

und ich brauche eine Erweiterung von Qt5, die sich eben nicht mit 4.9 übersetzen lässt, sondern erst mit 5.x, und eine Alpha-Version, die ich vom Entwickler habe, sogar nur mit 7.x.

Von welchem Rasberry Pi genau reden wir eigentlich? Auf einigen läuft auch Fedora, und das kommt our-of-the-box mit dem neusten Krempel.

https://www.heise.de/developer/meldung/ ... 55117.html
https://fedoraproject.org/wiki/Architec ... spberry_Pi
https://arm.fedoraproject.org/

Und ab nächstem Dienstag gibt es hier die 26 Beta mit gcc 7.1.1: https://arm.fedoraproject.org/prerelease.html

[DeletedUserReAsG]

Von welchem Rasberry Pi genau reden wir eigentlich? Auf einigen läuft auch Fedora, und das kommt our-of-the-box mit dem neusten Krempel.

Auf allen läuft Arch ARM, und da ist der Kam noch viel neuer, als bei Fedora

[owl102]

Auf allen läuft Arch ARM, und da ist der Kam noch viel neuer, als bei Fedora

Auf dem Pi 3 läuft openSUSE Tumbleweed, und da ist der Kram noch viel neuer, als bei Arch

https://en.opensuse.org/openSUSE:Supported_ARM_boards

[Meillo]

Ich zitiere aus dem Eingangsbeitrag:

Nochmals: Ich will kein neues Linux bauen, sondern das System nur hinsichtlich des GNU Toolchains auf den neuesten Stand bringen.

[...]

Soweit ich das bisher verstanden habe, liegt der Idee eher der Wunsch zugrunde, fremde Software bauen zu können; weniger der Wunsch, sich in die Interna einzuarbeiten. Das Ergebnis wäre in diesem Fall nicht egal.

Okay, dann stimme ich dir zu.

[DeletedUserReAsG]

Auf dem Pi 3 läuft openSUSE Tumbleweed, und da ist der Kram noch viel neuer, als bei Arch

Gentoo sollte auf allen Pis laufen, und noch viel neueren Kram haben :p

[scientific]

Ich hätt gern den Kernel vom September 2019!

[scientific]

Ich hätt gern den Kernel vom September 2019!

[MrScoville]

Warum nimmst du nicht einfach ein System, das deinen Ansprüchen bereits genügt?

Kann ich machen. Dann schreibe ich aber ungefähr mindestens 6 Treiber neu, um die Hardware anzusteuern, und die Visualisierung ist noch eine ganz andere Baustelle. Treiber neu schreiben... Da beißt sich die Katze in den Schwanz. Arme Katze.

Und noch einmal, hier geht es darum, möglichst wenige Taktzyklen zu verbraten, schon beim Starten des Systems. Bis Debian/Raspbian/Minibian mal den Allerwertesten hoch kriegt, sind schon zig Messergebnisse weg. Ich brauche kein Echtzeit-System, aber ich brauche eben auch nix von all dem Kram, den ein Standard-Kernel und seine Umgebung reinfressen, bis sie sich mal bereit melden.

[DeletedUserReAsG]

Dann schreibe ich aber ungefähr mindestens 6 Treiber neu, um die Hardware anzusteuern

Dieses verstehe ich nicht – es stellt für dich eine Option dar, zentrale Systembestandteile, und damit den ganzen Rest gleich mit, auszuwechseln, aber eine Handvoll Treiber neu zu kompilieren ist unmöglich? Ist ja nicht so, dass sich das API dramatisch geändert hätte …. Und wenn du einen selbstgebauten Kernel fahren willst, weil der Stock-Kernel dir zu fett ist, musst du die Treiber doch eh neu bauen?