GNU Toolchain selber bauen

[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?

[schorsch_76]

Die Gnu Toolchain ist ein ziemlich integraler Bestandteil des Systems. Du könntest in einer Chroot ein System fahren das bsp. den gcc 6.3 oder 7.1 nutzt.

Jessie nutzt noch gcc 4.x. Stretch und Co nutzen gcc 6.3. Zwischen 4.x und 5.x gab es einen ABI Wechsel bedingt durch C++11. Ja das betrifft die ganze ABI auch wenn du kein C++ nutzt. [1]

Wenn du sehr spezielle Bedürfnisse hast, kannst du auch buildroot nutzen um ein minimales System zu haben. Du scheinst sehr schnell von PowerOn zu Op gehen zu wollen. Wie wäre es, wenn du Suspend nutzt? Du könntest auch dein System komplett in die initramfs legen und dein Programm als Pid1 laufen lassen. Dann hast du keinerlei Overhead. (init=/usr/bin/meinprg).

Wenn du es dir nicht leisten kannst Messergebnisse zu verlieren, muss das System permanent an sein. Ich vermute du nutzt einen Pi da du Raspbian erwähnt hast. Hier würde ich das System wirklich laufen lassen.

[1] https://gcc.gnu.org/gcc-5/changes.html

[MrScoville]

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.

Na ja, Lernen ist immer was Gutes, aber Lernen als Selbstzweck lasse ich mal an der Uni.

Wunder, oh, Wunder, nachdem ich mich nun CLFS zugewendet habe, schau schau, da ist ein SysV-Branch, den man einfach (tatsächlich einfach) abspecken kann, und schon... Wird noch ein arges Reinfuchsen, weil schon die Doku dort fürs Bauen der Doku outdated ist, aber wenn's einfach wäre, könnte es ja jeder ^^

Also, Thema erledigt, und wenn ich noch Zeit finde, schreibe ich mal ne Doku

LG und schönen Rest-Sonntag noch

Carsten