Ich erinnere mal (wieder) an die Möglichkeit/Notwendigkeit, bei solchen Problemen das KOMPLETTE Build-Protokoll zur Verfügung zu stellen (mittels
fmake) - denn schon zwischen #1 und #2/#3 gibt es Diskrepanzen hinsichtlich der Stelle, wo das Problem auftritt (1x in
sched-rgn.c, 1x in
reload1.c) und der "Fehlercode" alleine ist noch lange keine Aussage, weil er lediglich zum Ausdruck bringt, wo der Fehler aufgetreten ist (eben beim Build für eine ältere GCC-Version).
Ich habe keine Ahnung, warum es für das hier wohl bei allen benutzte Ubuntu 21 keine vorübersetzte Toolchain gibt - das Problem tritt ja beim Erstellen des Cross-Compilers auf. Aber wenn es die nicht geben sollte (was ich wieder verstehen könnte, denn Ubuntu 21 anstelle von 20.04 LTS ist Unsinn, wie ich gleich versuchen werden zu erklären) bzw. wenn die Einstellungen das eigene Erstellen der Toolchain bewirken, muß eben erst einmal der passende GCC übersetzt werden, der auf der als Build-Host verwendeten Plattform das Erzeugen von Binärcode für die jeweilige FRITZ!OS-Plattform (das kann MIPS, ARM oder ATOM (x86+) sein) ermöglicht.
Mit 21.10 kam (iirc) bei Ubuntu der Umstieg auf GCC 11 - das wäre z.B. eine denkbare Stelle, wo durch das ständige (und m.E. vollkommen unnötige) Aktualisieren der Freetz-VM-Vorlage auch wieder ein Problem eingeschleppt worden sein könnte. Auch bei Verwendung von 21.04 kann es bei Updates zur Installation eines anderen GCC kommen - solange man auf einem System, mit dem man Freetz-Builds ausführen will, nicht auch noch mit anderen (Linux-)Programmen arbeiten will, braucht es am Ende aber nur Security-Fixes - wenn man kein ganz altes Build-System verwendet (vor 18.04 LTS).
Die LTS-Versionen (und die gibt es bei Ubuntu ja immer in Abständen von zwei Jahren:
https://wiki.ubuntuusers.de/Long_Term_Support/) kriegen lange genug ihre Updates (und Ubuntu 21 ist nun mal keine Version, bei der es überhaupt ein LTS-Release gäbe), so daß man mit einer einmal funktionierenden VM (oder Side-by-Side-Installation für die Benutzung der Freetz-Toolchain) auf sehr, sehr lange Zeit "auf der sicheren Seite" ist und das Update für den Build-Host (wie gesagt, solange man nicht ständig mit dieser VM auch an anderer Stelle arbeitet - was dann aber sicherlich größere eigene "Expertise" bewirkt, bei der man sich auch selbst helfen kann bei Problemen wie oben) ist (a) vollkommen unnötig und (b) sogar "dumm", wenn man sich damit entsprechende Fehler neu einschleppt.
Es gibt nun mal bei Linux-Distributionen eine noch viel größere Bandbreite an möglichen Kombinationen, als bei Windows oder dem Apple-Zeug - das KANN dann einfach niemand mehr (alleine) testen, zumindest nicht in Kombination mit den (notwendigen) Regression-Tests ... denn wenn jetzt wieder Änderungen für GCC 11 notwendig sein sollten, wären sicherlich die Benutzer älterer/anderer Build-Systeme dann auch wieder verärgert, wenn diese Änderungen dazu führen, daß ihre Build-Systeme nicht mehr funktionieren. Für das Ergebnis in Form eines modifizierten Firmware-Images ist es aber vollkommen Banane, ob dafür nun der "neueste" GCC beim Erstellen der Cross-Development-Toolchain benutzt wurde oder nicht - es gibt also GAR KEINE Notwendigkeit, den Build-Host (abseits von Security-Fixes, die dann auch als solche ausgewiesen werden) irgendwie zu aktualisieren.
Mein Tipp also (neben dem ganz oben, daß man schon passende Protokolle vorzeigen muß, wenn man erwartet, daß sich jemand das Problem ansieht - dazu ist wahrlich genug schon geschrieben worden, seit dem "Anbeginn" von Freetz): Benutzt einfach eine der LTS-Versionen von Ubuntu für Eure Freetz-(NG-)Builds und hört auf mit dem Unsinn, dieses System (jenseits von Security-Fixes) ständig zu aktualisieren. Wenn so ein Update für das Build-System tatsächlich einmal notwendig sein/werden sollte, erfahrt Ihr das noch früh genug - diese Updateritis schadet jedenfalls deutlich mehr, als daß sie irgendeinen Nutzen bringen würde. Gerade die Freetz-VM mit ihrem ohnehin beschränkten Funktionsumfang ist ja nun kein System, was man auch für alle möglichen anderen Aufgaben heranziehen wollte - wer sich aus dieser VM erst ein "vollständiges" Linux-System bauen will, der wäre deutlich besser dran, wenn er "from scratch" beginnt und auch dafür/daher braucht es dann wieder keine Freetz-VM mit dem "aktuellsten" Ubuntu-Release.
Vielleicht sollten alle mit dem hier beschriebenen "Problem" also einfach mal einen Schritt zurück machen und sich ein entsprechendes Image mit 20.04 LTS (es ginge sogar 18.04 LTS) besorgen, in dem man dann den Freetz-Build erneut probieren kann. Erst wenn auch da dann Probleme auftreten, lohnt sich tatsächlich die Suche nach deren Ursache - irgendwelche Problemchen, die durch halbjährliche Updates einer Distribution eingeschleppt werden, sind so unnötig wie ein Kropf.
Ich habe noch nicht in GitHub nachgesehen, ob/was
@cuma da (etwas) unternommen hat - aber es ist (aus den o.a. Gründen) auch nicht sinnvoll, alle sechs Monate erneut über derartige Probleme zu klagen, wenn man sie doch letztlich selbst zu verantworten hat. Zumal ich jetzt mal die These aufstelle, daß es nicht wirklich ausführliche Regression-Tests nach solchen Änderungen gibt und damit die (durchaus reale) Gefahr besteht, daß diejenigen, die tatsächlich (vernünftigerweise) mit LTS-Versionen arbeiten, dann von entsprechenden Korrekturen auch negativ betroffen sein können.
Das Ziel der meisten dürfte es ja eher sein, ein funktionierendes Image für ihre FRITZ!Boxen zu erzeugen und nicht, bei jedem neuen Build erst mal die VM komplett neu einzurichten, nur weil seit dem letzten AVM-Release auch eine neue Ubuntu-Version erschienen ist und die Freetz-VM bzw. die Freetz-Toolchain jetzt erst mal wieder neu erstellt werden müssen/sollen, weil Änderungen für neue Ubuntu-Versionen dazu führen, daß die aktuelle Freetz-(NG-)Version nicht mehr auf älteren LTS-Versionen funktioniert.
