Toolchain-Build für 7590 schlägt fehl

[Bodenseematze]

Hallo,

ich habe seit ziemlich langer Zeit kein Freetz-NG Image mehr für meine 7590 Box(en) gebaut / bauen können, weil in meiner Ubuntu-VirtualBox-VM immer das Bauen der Toolchain fehl schlägt.

Ich habe das hier noch nicht gemeldet, weil ich immer sehr wenig Zeit habe und: die Box läuft ja ;-)

Jetzt will ich aber endlich mal auf eine neuere Firmware-Version (bin noch auf 07.29) gehen und endlich mal wieder Freetz-NG images bauen (können)...

Aktuell läuft meine Freetz Build-Umgebung mit Ubuntu 23.10 (mit allen Updates) in einer VirtualBox-VM; VirtualBox ist ebenfalls aktuell (7.0.14)

Als Fehlermeldung kommt beim Bauen folgende letzte Fehlerzeilen:

`g++  -I/home/freetz/workdir/7590/source/toolchain-mips_gcc-13.2.0_uClibc-1.0.45-nptl_kernel-4.9/gcc-13.2.0/libcpp -I. -I/home/freetz/workdir/7590/source/toolchain-mips_gcc-13.2.0_uClibc-1.0.45-nptl_kernel-4.9/gcc-13.2.0/libcpp/../include -I/home/freetz/workdir/7590/source/toolchain-mips_gcc-13.2.0_uClibc-1.0.45-nptl_kernel-4.9/gcc-13.2.0/libcpp/include  -march=34kc -mtune=34kc -msoft-float -Ofast -pipe -Wa,--trap -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Wl,-I/usr/lib/freetz/ld-uClibc.so.1     -W -Wall -Wno-narrowing -Wwrite-strings -Wmissing-format-attribute -pedantic -Wno-long-long  -fno-exceptions -fno-rtti -I/home/freetz/workdir/7590/source/toolchain-mips_gcc-13.2.0_uClibc-1.0.45-nptl_kernel-4.9/gcc-13.2.0/libcpp -I. -I/home/freetz/workdir/7590/source/toolchain-mips_gcc-13.2.0_uClibc-1.0.45-nptl_kernel-4.9/gcc-13.2.0/libcpp/../include -I/home/freetz/workdir/7590/source/toolchain-mips_gcc-13.2.0_uClibc-1.0.45-nptl_kernel-4.9/gcc-13.2.0/libcpp/include    -c -o charset.o -MT charset.o -MMD -MP -MF .deps/charset.Tpo /home/freetz/workdir/7590/source/toolchain-mips_gcc-13.2.0_uClibc-1.0.45-nptl_kernel-4.9/gcc-13.2.0/libcpp/charset.cc`
`as: unrecognized option '--trap'`
`cc1plus: error: bad value ‘34kc’ for ‘-march=’ switch`
`cc1plus: note: valid arguments to ‘-march=’ switch are: nocona core2 nehalem corei7 westmere sandybridge corei7-avx ivybridge core-avx-i haswell core-avx2 broadwell skylake skylake-avx512 cannonlake icelake-client rocketlake icelake-server cascadelake tigerlake cooperlake sapphirerapids emeraldrapids alderlake raptorlake meteorlake graniterapids graniterapids-d bonnell atom silvermont slm goldmont goldmont-plus tremont gracemont sierraforest grandridge knl knm x86-64 x86-64-v2 x86-64-v3 x86-64-v4 eden-x2 nano nano-1000 nano-2000 nano-3000 nano-x2 eden-x4 nano-x4 lujiazui k8 k8-sse3 opteron opteron-sse3 athlon64 athlon64-sse3 athlon-fx amdfam10 barcelona bdver1 bdver2 bdver3 bdver4 znver1 znver2 znver3 znver4 btver1 btver2 native`
`cc1plus: error: bad value ‘34kc’ for ‘-mtune=’ switch`
`cc1plus: note: valid arguments to ‘-mtune=’ switch are: nocona core2 nehalem corei7 westmere sandybridge corei7-avx ivybridge core-avx-i haswell core-avx2 broadwell skylake skylake-avx512 cannonlake icelake-client rocketlake icelake-server cascadelake tigerlake cooperlake sapphirerapids emeraldrapids alderlake raptorlake meteorlake graniterapids graniterapids-d bonnell atom silvermont slm goldmont goldmont-plus tremont gracemont sierraforest grandridge knl knm intel x86-64 eden-x2 nano nano-1000 nano-2000 nano-3000 nano-x2 eden-x4 nano-x4 lujiazui k8 k8-sse3 opteron opteron-sse3 athlon64 athlon64-sse3 athlon-fx amdfam10 barcelona bdver1 bdver2 bdver3 bdver4 znver1 znver2 znver3 znver4 btver1 btver2 generic native`
`make[4]: *** [Makefile:227: charset.o] Error 1`
`make[3]: *** [Makefile:3060: all-build-libcpp] Error 2'`

Das komplette Log-File habe ich angehängt (7590_2024-01-31_log.zip)

Das ganze scheint mir unabhängig von der eigentlichen Konfiguration zu sein - ich habe testweise auch einmal nur einfach die 7590 ausgewählt und dann versucht, das zu bauen - da kommt der gleiche Fehler

[fda77]

hast du mit dieser .config auch für ein anderes gerät/fos gebaut? es könnten noch überreste bzw falsche parameter drinnen sein

[Bodenseematze]

Nein, habe ich nicht - allerdings ist meine eigentliche .config tatsächlich sehr alt und immer wieder über "make oldconfig" weitergeschrieben worden.
Ich werde es jetzt mal nochmal "neu" versuchen...

[aus-sua]

Ich habe einmal:
"cc1plus: error: bad value ‘34kc’ for ‘-march=’ switch`"
in google eingeworfen.
Neben vielen (wohl nur ähnlichen) Fehlern landet man(n) aber auch bei:
https://www.ip-phone-forum.de/threads/freetz-ng-fehler-beim-bauen-f%C3%BCr-unterschiedliche-konfigurationen.308030/

Lassen wir 'mal das ganze blah... dort weg, dann scheint ja das:
https://www.ip-phone-forum.de/threads/freetz-ng-fehler-beim-bauen-f%C3%BCr-unterschiedliche-konfigurationen.308030/post-2485994
der richtige Ansatz zu sein, das Problem richtig sauber zu lösen.
@fda77 --> Wenn ich mich da jetzt richtig erinnere, ist das doch aber auch schon in freetz-NG eingeflossen?!
(wie sucht man so etwas "ist eingeflossen am/von" im aktuellem github?)

Wenn es also schon in freetz-NG eingepflegt wurde, bleiben "die üblichen Verdächtigen":

• install prerequisites
• nicht (sauber) aktualisiertes linux
• immer wieder mitgeschleppte (uralte...) .config
• verkonfiguriertes freetz-NG
• verkonfigurierte vm/vm-parameter
  usw.usw...

@Bodenseematze
hilfreich ist immer auch Deine .config und Deine .config.compressed

Auf meiner vm mit Ubuntu 22.04.3 LTS (Kernel 5.15.0-91-generic x86-64)
läuft das fmake (nach quasi nur 7590 ausgewählt) ohne Probleme durch. fmake_conf_conf.comp_.zip

[fda77]

Ach, es geht um Compiler auf dem Target... Dass wirklich niemand es hinbekommt dazuzuschreiben um was es geht!
Ne, die DHU Dinge sind nicht eingeflossen. Ich hatte den mal vor sehr langem kontaktiert, es gab aber keinerlei Rückmeldung.
Vieles bräuchte auch noch Nacharbeit und ich hab es dann sein gelassen

Jedenfalls gibt es bei NG vieles neues wie gcc v8+v13 und auch andere Tools wie binutils .. ich weiss nicht genau was fürs target selbst gebaut wird. Ich hab das jedenfalls noch NIE verwendet, da kann es gut sein dass das nicht funktioniert.
Da man zum testen

1. die toolchain selbst bauen muss
2. und daszu auch noch ccache ausschalten muss

hab ich auch gar keine Lust da irgend was zu machen, das dauert alles Ewig zu compilieren.
Ich versteck es einfach hinter "DEVELOPER" und wer sich als sich einer füht wird es bestimmt auch fixen können - falls es nicht geht (ich geh davon aus da es mehr als 1 Bericht gibt)
Die meisten machen das vermutlich eh nur an weil es die Option nun mal gibt

[fda77]

0e5a4cb

[Bodenseematze]

Ähhm - sorry, wenn ich irgendwas nicht "dazugesschrieben" habe; aber wenn Du das noch nie verwendet hast, brauche ich es sicher auch nicht.
Nur: ich habe keine Ahnung, warum das bei mir gebaut wird!?

Mein Level ist nicht auf "DEVELOPER" sondern 'nur' auf "EXPERT" - und eigentlich will ich doch nur ein Image für meine 7590-Boxen bauen... (zugegeben: in meiner normalen Konfiguration ist ziemlich viel nutzloses Zeug drin - ich muss da mal ausmisten)
...wieso da jetzt eine toolchain für's Target gebaut wird, weiß ich nicht!?

Da ich ja sowieso mal neu (mit der .config) anfangen will, starte ich mal in einem leeren Clone-Verzeichnis neu...

Ich melde mich hier wieder, ob da der Fehler auch auftritt (wenn's nur nicht immer so lange dauern würde...)!

[fda77]

Noch besser :) Der letzte meinte auch dass er die Option ausmacht da er sie eh nicht braucht...
Jedenfalls ist dieses Toolchain für das target um auf der Fritzbox zu compilieren.
Mit dem Commit oben ist diese Option AB HEUTE nur noch für "DEVELOPER" sichtbar.
Also einfach ein git-pull und direkt danach make.

[Bodenseematze]

Ich habe in einem neuen Clone-Verzeichnis neu mit der Konfiguration begonnen.
Hier kommt dann beim Bauen ein anderer Fehler - ist aber ebenfalls im toolchain-Verzeichnis...

Die Log-Datei 7590.neu_2024-02-02.log.zip und die verwendete Config config_7590.neu_2024-02-02.txt habe ich angehängt...

[pfichtner]

Frisch gecloned bzw. aktualisert (pull)?
Sieht nach #938 2fc15d8 aus

[Bodenseematze]

Seufz - da war ich wohl zu früh dran...
Habe heute nochmal ein pull gemacht - dann war nur noch ein Fehler beim Bau des Pakets "squashfs-tools 4.3"; die brauche ich aktuell aber auch nicht zwingend, also habe ich das Paket deaktiviert und dann liess sich das Image bauen
Jetzt muss ich es nur noch erfolgreich / lauffähig auf die Box(en) spielen ;-)

EDIT: auf meiner Garagen-Box hat das Aufspielen jetzt erfolgreich geklappt - auf meiner (Router-)Hauptbox werde ich es als nächstes versuchen...

[Bodenseematze]

Noch eine ergänzende Frage:
funktioniert eigentlich das Freetz-NG Wireguard-Paket, wenn das AVM-Wireguard nicht rausgepatcht wurde?
Ich habe mir das von AVM jetzt mal angeschaut - da habe ich aber zu wenig Möglichkeiten gefunden, Server-Einstellungen zu setzen - deswegen wollte ich wieder das von Freetz-NG aktivieren.
Das läuft auch scheinbar - nur kann ich von Remote aus keine Verbindung aufbauen, da klappt lt. Logging der Handshake nicht... :-(

[fda77]

Keine Ahnung! Ich werfe die meisten AVM-Dinge meist raus. Das AVM-Wireguard hab ich noch nie gesehen. Auch patcht AVM gerne in Programmen herum .. du könntest in den Sourcen schauen ob avm da wirklich was gemacht hat.
Ansonsten hilft nur ausprobieren :) Wenn man wirklich nicht beide im Image haben darf, sollte das freetz paket automatisch den remove-patch auswählen

[Bodenseematze]

ich werde es voraussichtlich heute Abend neu compilieren - dann berichte ich, ob es nach dem Remove-Patch funktioniert...

[Bodenseematze]

Hmm - auch mit dem Remove-Patch funktioniert meine Wireguard-Verbindung (über das Freetz-NG Paket) von außen nicht mehr :-(
Die Verbindung an sich klappt, dann steht aber im Protokoll, dass der Server nicht auf den Handshake antwortet (Handshake for peer did not complete after 5 seconds, retrying)...
Ein ping auf die Wireguard Server-IP funktioniert demzufolge auch nicht - da muss ich mal weiter analysieren, warum das nicht funktioniert (ist aber nicht so einfach, weil ich ja immer "von außen" testen muss und über das Smartphone geht's daheim nicht, weil ich keinen Mobilfunkempfang habe...)
Unter Umstängen ist das hier dann einen eigenen Thread wert ;-)

Übrigens kommt es mir so vor, als ob die 7.57er Firmware nicht so rund wie die 7.29er läuft - auch der AVM dsld ist immer mal wieder weg und ich muss ihn per Freetz-Oberfläche beu starten...

[fda77]

Bei AVM besteht "Sicherheit" darin per default ping nicht zu beantworten. Das musss man extra einschalten! Dazu ist das Fritzos so schlecht dass maximal nur 1em Gerät auf pings geantwortet werden kann! Das ist sei dem "packet accelerator" vor vielen Jahren so. Da senn irgend jemand dein Gerät anpingt bekommst du auch keine Antworten von deinem Router.
Ansonsten schau ober der Daemon läuft und auf welchem Port und ob das freigegeben ist

[Bodenseematze]

Ich habe noch eine andere 7590 FritzBox mit Freetz-NG als Wireguard-Gegenstelle zum Testen - dort läuft noch die alte 7.29er Firmware und wenn dort die Verbindung steht, lässt sich die Server-Gegenstelle (also der Wireguard-Server) problemlos anpingen;
dort kommt auch direkt nach dem "Startup complete" ein "Receiving handshake response from peer" im Logging - was eben bei meiner 7.57er-Gegenstelle nicht kommt...
Aber vielleicht ist da irgendwas mit den Schnittstellen anders geworden?!

Ich glaube, ich schreibe das ganze doch mal in einem neuen Thread, damit der hier endgültig zu bleiben kann ;-)
Danke nochmal für Deine Hilfe bzgl. Build etc.

[fda77]

Wenn ich raten müsste würde ich auf Konfigurationsfehler tippen. In Fritzos gab es da nicht so viele Änderungen :)

[Bodenseematze]

Naja, an der Konfiguration habe ich nichts geändert; vor dem Firmware-Update auf das 7.57er-Image hatte das funktioniert...
Ich boote mal die andere Partition, da ist das 7.29er noch drauf - werde aber erst morgen / übermorgen dazu kommen...

[fda77]

Also ging mit der Alten Wireguard von AVM und Freetz gleichzeitig?

[Bodenseematze]

Nein - bei der 7.29er gab es Wireguard von AVM noch nicht - das wurde von AVM erst ins "große" Update 7.50 eingeführt.

Inzwischen habe ich die andere Partition mit 7.29 gebootet - und ich kann auf Anhieb wieder meine Wireguard-Verbindung aufbauen!
Also irgendwas muss sich zw. 7.29 und 7.50/7.57 soweit geändert haben, dass zumindest eine bestehende Wireguard-Konfiguration nicht mehr funktioniert.
Mal schauen, ob ich im Logging was feststellen kann - auf jeden Fall mache ich hier jetzt erst einmal einen neuen Thread dafür auf!

[fda77]

Also irgendwas muss sich zw. 7.29 und 7.50/7.57 soweit geändert haben

Das liest man hier ständig, kapiert ihr es wirklich nicht dass mit einem anderen Fos sich alles ändern kann?
Wenn sich also wie du schreibst mit 7.2x und 7.5x alles gleich ist, warum nicht 7.2x verwenden? Es gibt ja keine Unterschiede, oder so

[Bodenseematze]

Naja, nachdem es doch dieses Riesen Sicherheitsleck bei den FritzBoxen gab (zumindest wenn man der Presse glauben darf) und dieses erst mit 7.57 gefixt wurde, ist mir schon eine Weile unwohl mit meinen 7.29 Versionen...

https://www.heise.de/hintergrund/Fritzbox-Sicherheitsleck-analysiert-Risiken-und-Gegenmassnahmen-9323225.html

Außerdem gibt es schon Unterschiede zw. 7.29 und 7.57 - nur halt nicht beim Wireguard-Paket!?

[fda77]

Ist es nicht so dass du selbst festgestellt hast dass in der 7.2 noch gar kein Wireguard von avm gibt?

[Bodenseematze]

Ja, ich meinte, dass sich das Freetz-NG Paket nicht verändert hat und deswegen "sollte" es doch sowohl in 7.29 als auch in 7.57 funktionieren - Mensch ist das verwirrend hier ;-)

In Fritzos gab es da nicht so viele Änderungen :)

Das liest man hier ständig, kapiert ihr es wirklich nicht dass mit einem anderen Fos sich alles ändern kann

Was denn jetzt - hat es nicht so viele Änderungen gegeben oder hat sich alles geändert?!
Entschuldigung, aber ich bin jetzt total verwirrt...

[fda77]

Du hast gesagt dass du nichts geändert hast aber ein komplett anderes Fos nutzt