[Problem] [freetz-ng] Fehler beim Compilieren für FritzBox 7580

[ronny_b]

Hallo,

laut https://freetz-ng.github.io/freetz-ng/FIRMWARES.html#fritzbox-fon-wlan-75xx sollte sich die aktuelle Firmware 7.28 für die Fritzbox 7580 compilieren lassen. Ich bekomme aber leider eine Fehlermeldung:

/bin/bash /home/ronny/freetz/freetz-ng/source/toolchain-mips_gcc-8.3.0_uClibc-1.0.37-nptl_kernel-4.9/gcc-8.3.0/gcc/../move-if-change tmp-optionlist optionlist
echo @set srcdir /home/ronny/freetz/freetz-ng/source/toolchain-mips_gcc-8.3.0_uClibc-1.0.37-nptl_kernel-4.9/gcc-8.3.0/gcc >> gcc-vers.texiT
if [ -n "(GCC) " ]; then \
  echo "@set VERSION_PACKAGE (GCC) " >> gcc-vers.texiT; \
fi
echo "@set BUGURL @uref{https://gcc.gnu.org/bugs/}" >> gcc-vers.texiT; \
mv -f gcc-vers.texiT gcc-vers.texi
echo timestamp > s-options
g++ -c   -D_GNU_SOURCE -fno-stack-protector -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE   -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -I. -Ibuild -I/home/ronny/freetz/freetz-ng/source/toolchain-mips_gcc-8.3.0_uClibc-1.0.37-nptl_kernel-4.9/gcc-8.3.0/gcc -I/home/ronny/freetz/freetz-ng/source/toolchain-mips_gcc-8.3.0_uClibc-1.0.37-nptl_kernel-4.9/gcc-8.3.0/gcc/build -I/home/ronny/freetz/freetz-ng/source/toolchain-mips_gcc-8.3.0_uClibc-1.0.37-nptl_kernel-4.9/gcc-8.3.0/gcc/../include  -I/home/ronny/freetz/freetz-ng/source/toolchain-mips_gcc-8.3.0_uClibc-1.0.37-nptl_kernel-4.9/gcc-8.3.0/gcc/../libcpp/include  \
    -o build/gengenrtl.o /home/ronny/freetz/freetz-ng/source/toolchain-mips_gcc-8.3.0_uClibc-1.0.37-nptl_kernel-4.9/gcc-8.3.0/gcc/gengenrtl.c
g++ -c   -D_GNU_SOURCE -fno-stack-protector -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE   -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -I. -Ibuild -I/home/ronny/freetz/freetz-ng/source/toolchain-mips_gcc-8.3.0_uClibc-1.0.37-nptl_kernel-4.9/gcc-8.3.0/gcc -I/home/ronny/freetz/freetz-ng/source/toolchain-mips_gcc-8.3.0_uClibc-1.0.37-nptl_kernel-4.9/gcc-8.3.0/gcc/build -I/home/ronny/freetz/freetz-ng/source/toolchain-mips_gcc-8.3.0_uClibc-1.0.37-nptl_kernel-4.9/gcc-8.3.0/gcc/../include  -I/home/ronny/freetz/freetz-ng/source/toolchain-mips_gcc-8.3.0_uClibc-1.0.37-nptl_kernel-4.9/gcc-8.3.0/gcc/../libcpp/include  \
    -o build/genhooks.o /home/ronny/freetz/freetz-ng/source/toolchain-mips_gcc-8.3.0_uClibc-1.0.37-nptl_kernel-4.9/gcc-8.3.0/gcc/genhooks.c
/tmp/ccoeOWUu.s: Assembler messages:
/tmp/ccoeOWUu.s:916: Error: alignment too large, 28 assumed
/tmp/ccoeOWUu.s:1545: Error: unrecognized opcode `pushq %rbp'
/tmp/ccoeOWUu.s:1548: Error: unrecognized opcode `movq %rsp,%rbp'
/tmp/ccoeOWUu.s:1550: Error: unrecognized opcode `subq $16,%rsp'
/tmp/ccoeOWUu.s:1551: Error: unrecognized opcode `movl %edi,-4(%rbp)'
/tmp/ccoeOWUu.s:1552: Error: unrecognized opcode `movl -4(%rbp),%eax'
/tmp/ccoeOWUu.s:1553: Error: unrecognized opcode `subl $66,%eax'

Der gleiche Prozeß für meine 2. Box 7520 lief dagegen problemlos durch.

Was habe ich schon probiert?
- Verzeichnis leeren mit 'make dirclean'
- Freetz-NG komplett jungfräulich aus dem .git geladen und auch die .config neu erstellen lassen. Danach nur die Box auf 7580 geändert und 'make' ausgeführt.

Ich würde mich freuen, wenn mir jemand helfen kann. Wenn noch weitere Daten benötigt werden, einfach fragen. Bauen tue ich das ganze auf einem aktuellen Debian-stable.

Danke im Voraus, Ronny

 

[gismotro]

Ich versuche es mal auf meiner VM

 

[PeterPawn]

Bauen tue ich das ganze auf einem aktuellen Debian-stable.

Auch auf einer x86/x64-Maschine?

Es sieht so aus, als enthielte der Assembler-Code, der aus den C-Quellen des GCC generiert wird, unbekannte Operationscodes für die Plattform, auf der das am Ende laufen soll (als Cross-Compiler) - zumindest ungültig für die Plattform, die der Assembler am Ende als Ziel für die Übersetzung ansieht.

Merkwürdig ist aber schon, wenn das erst in Zeile 1545 der (temporären) Assembler-Datei auffallen soll, daß die Instruktionen pushq, movq und subq nicht bekannt sind (die arbeiten jeweils mit 64-Bit, die Instruktionen mit einem l am Ende hingegen mit 32 Bit) und daß danach sogar 32-Bit-Instruktionen nicht bekannt sein sollen - außer die Zeilen am Beginn der (temporär verwendeten) Assembler-Datei sind alle ausgesprochen "plattformunabhängig".

Ich würde hier dennoch am ehesten auf einen Konflikt bei der Auswahl der Plattform, auf welcher der Cross-Compiler arbeiten soll, tippen - event. hast Du aber auch nur eine Option zuviel ausgewählt, die nicht richtig unterstützt wird ... nämlich das Erstellen der Toolchain auch "für das Zielgerät", also eine Toolchain, die direkt auf dem MIPS-Prozessor der 7580 arbeiten kann und dort dann auch die passenden MIPS-Binaries für die Box erstellt.

Ich weiß gerade aus dem Kopf auch nicht mehr, wie die Option heißt - andererseits spricht ja dagegen, daß Du nach eigener Aussage nur das Modell des Ziels eingestellt hast und der Rest nur automatisch gesetzte Einstellungen wären (das erspart mir auch das Nachschlagen, wie die Option hieße).

Aber dennoch wäre sicherlich die verwendete Konfigurationsdatei (sowohl die "normale" als Anhang, als auch die komprimierte, die man auch mal als CODE-Block einfügen kann) auch nützlich bei der Spekulation, woran es ansonsten noch liegen könnte - ebenso wie die (umfassende) Beschreibung der Plattform, auf der das Build-System arbeiten soll. Nur "Debian-stable" ist da etwas mager - schließlich gibt es da auch den Support für 64-Bit-ARM und es kann genauso gut eine solche Plattform sein.

Wie es da dann um die Unterstützung eines passenden 32-Bit-Cross-Compilers für MIPS-Plattformen bestellt sein mag, weiß hier (vermutlich jedenfalls) auch nicht jeder aus dem Kopf und ich würde genauso nicht beschwören wollen, ob alle "automatischen" Einstellungen auch berücksichtigen, daß ein 64-bittiger Build-Host mittlerweile auch etwas anderes als eine x64-Plattform sein könnte.

 

[gismotro]

In der VM läuft der Build ohne Probleme:

STEP 3: PACK/SIGN
  checking for left over version-control-system files
  integrate freetz info file into image
packing var.tar
  checking signature key files
    creating private signature key file
    creating public signature key file
    adding public signature key file
creating filesystem image (SquashFS4-xz)
  SquashFS block size: 64 kB (65536 bytes)
copying kernel image
  kernel image size: 6.0 MB, max 8.0 MB, free 2.0 MB (2092032 bytes)
copying filesystem image
  filesystem image size: 25.6 MB, max 44.0 MB, free 18.4 MB (19333120 bytes)
adding checksum to kernel.image
adding checksum to filesystem.image
packing images/7580_07.28.ger_freetz-ng-18635-31df8b7ab_20211105-131727.image
  packed image file size: 31.7 MB (33290240 bytes)
signing packed .image file
  signed image file size: 31.7 MB (33290240 bytes)
source firmware: 7580_de-es-fr-it-pl 153.07.28 rev90134 {GER} [PSQ19P2NL3-Go0phie0] (05.08.2021 09:47:28)
  source image file size: 31.2 MB (32675840 bytes)
done.

FINISHED
freetz@freetz:~/test$

 

[ronny_b]

Danke für die ausführliche Antwort. Da der Compiler für die 7520 vor einigen Tagen noch problemlos durchlief, hatte ich weniger mein System in Verdacht. Hier also ausführlicher:

Intel Pentium J5005
5.10.0-9-amd64
gcc 10.2.1

Habe ich noch was vergessen?

Die Option habe ich gefunden:

# FREETZ_TARGET_TOOLCHAIN is not set

Meine verwendete '.config' habe ich angehängt.

Ronny

 

[Micha0815]

Lese ich da etwa user_competence Beginner? auf meinem Schlauphone? Damit gab/gibt es imho Probleme.
LG and my 2cent da die Anzeige etwas dürftig ohne richtigen Monitor

 

[ronny_b]

Ja, weil das die neu erstellte '.config' ist, wo ich nur die FritzBox geändert habe. Ansonsten habe ich das auf "Experte" stehen (wofür ich mich aber nicht halte ).

 

[Master SaMMy]

Also bei mir lauf die config ohne probs durch

STEP 3: PACK/SIGN
checking for left over version-control-system files
integrate freetz info file into image
packing var.tar
checking signature key files
adding public signature key file
creating filesystem image (SquashFS4-xz)
SquashFS block size: 64 kB (65536 bytes)
copying kernel image
kernel image size: 6.0 MB, max 8.0 MB, free 2.0 MB (2092032 bytes)
copying filesystem image
filesystem image size: 25.6 MB, max 44.0 MB, free 18.4 MB (19296256 bytes)
adding checksum to kernel.image
adding checksum to filesystem.image
packing images/7580_07.28.ger_freetz-ng-18636MOA-5f0dbe151_20211105-191655.image
packed image file size: 31.8 MB (33331200 bytes)
signing packed .image file
signed image file size: 31.8 MB (33331200 bytes)
source firmware: 7580_de-es-fr-it-pl 153.07.28 rev90134 {GER} [PSQ19P2NL3-Go0phie0] (05.08.2021 11:47:28)
source image file size: 31.2 MB (32675840 bytes)
done.

 

[PeterPawn]

Da der Compiler für die 7520 vor einigen Tagen noch problemlos durchlief

Da die ARM ist (und nicht REICH), wäre ein ARM-basierter Build-Host die erste Möglichkeit gewesen, die mir (bei diesem Fehler und den Meldungen) in den Sinn gekommen ist. Aber das kann man ja dann abhaken - nur scheint es auf anderen Build-Hosts ja auch problemlos zu laufen.

Bitte wiederhole das Ganze noch einmal ... mit der Minimal-Konfiguration und mit einem frischen Checkout, wie Du es laut #1 ja schon einmal gemacht hast. Diesmal aber bitte den entscheidenden Schritt (das make nach dem make menuconfig) mit ./fmake machen (das ist ein Shell-Skript in der Freetz-Wurzel, was auch eine Hilfe anbietet, wenn man es mit --help aufruft) und hänge das komplette Protokoll des Builds hier an als Text-Datei. Das eigentliche Problem liegt wahrscheinlich irgendwo weiter vorne und ist aus dem kurzen Protokoll-Ausschnitt in #1 nicht zu ersehen. Es geht schon beim Download der passenden Sourcen los - da sollte man deren Namen sehen können.

Wobei mich das auch wieder an etwas erinnert ... in Freetz-NG werden die Downloads alle unterhalb des Home-Verzeichnisses des Benutzers gespeichert und ggf. nicht gelöscht bei irgendwelchen Aufräumarbeiten - gerade dann, wenn man da unterschiedliche Plattformen verwenden will, KÖNNTE das auch noch ein Problem sein.

Also schau bitte auch ins Home-Verzeichnis des verwendeten Benutzers - irgendwo da muß sich ein Verzeichnis dl von Freetz-NG herumtreiben (ich weiß auch nicht mehr genau, wo das ist - ich weiß nur noch, daß ich darüber mal ziemlich lange mit @cuma in irgendeiner GitHub-Seite palavert habe, ob das wirklich Sinn macht) und vielleicht löst sich Dein Problem auch schon dadurch, daß Du einfach mal dessen Inhalt komplett entsorgst (oder es zumindest umbenennst) - das wird vom Build (bzw. schon vom make menuconfig) dann automatisch wieder angelegt und als dl unterhalb des Freetz-NG-Checkouts verlinkt. Nur dann werden auch die Pakete tatsächlich neu geladen aus dem Netz - bringt natürlich entsprechenden Traffic mit sich. Aber auch bei so einem Versuch kann man dann gleich das Protokoll des Builds speichern lassen - es ist also alles ein Aufwasch.

 

[ronny_b]

Das mit dem 'dl'-Verzeichnis ist ein guter Gedanke. Ich habe die Downloads auch schon im freetz zentral abgelegt, schon weil mein Internet damals noch so extrem langsam war. Gerade habe ich gesehen, daß da noch Dateien von 2007 enthalten sind. Das sollte dringend mal geleert werden...

Ich werde das testen und melde mich wieder, Danke!

Ronny

 

[ronny_b]

So, ich habe das 'dl'-Verzeichnis geleert. Danach

make dirclean
git pull

die '.config' gelöscht und in

make menuconfig

nur die Box auf 7580 umgestellt. Im Anhang ist nochmal die verwendete '.config' und die Ausgabe von

./fmake

welches leider immer noch in den Fehler läuft.

Ronny

 

[PeterPawn]

Der Fehler:

/tmp/ccVdmrgM.s:916: Error: alignment too large, 28 assumed

stammt mit großer Wahrscheinlichkeit daher, daß bei MIPS-Assembler die Größenangabe in einem .align-Statement angibt, auf welches Vielfache von 2 da ausgerichtet werden soll (das hier: https://github.com/PeterPawn/YourFr..._kernel_config/avm_kernel_config_macros.h#L17 bedeutet also z.B. eine Ausrichtung an einer durch 16 teilbaren Adresse).

Der Fehlernachricht nach zu urteilen, wurde da aber ein Statement erzeugt (vom g++), welches direkt die Ausrichtung ALS Zahlenangabe (in Bits) enthält. Da das vermutlich 32 oder noch größer sein dürfte und damit den Adressraum des Prozessors aber sprengen würde (2 ^^ 32 = 4.294.967.296), wurde der Wert verringert auf 28 (2 ^^ 28 = 268.435.456) - EDIT: die obersten Bits eine MIPS-Adresse haben eine spezielle Bedeutung dafür, wie genau auf den Speicher zugegriffen wird.

Soviel zum "Inhalt" der ersten Fehlermeldung, wenn man die der Reihe nach "abarbeiten" wollte - nur erklärt das zwar den Inhalt der Meldung (die man ggf. durch manuellen Aufruf des g++ mit Speichern der erzeugten Assembler-Quellen (Option --save-temps) noch verifizieren könnte), aber leider noch nicht, warum da offenbar ein falscher gas verwendet wird (der wird intern vom g++ für die erzeugten temporären Assembler-Dateien aufgerufen), denn allem Anschein nach ist das ja bereits irgendeiner, der MIPS-Code erzeugen will ... und das dürfte das eigentliche Problem sein, was dann sowohl die Empörung über das .align-Statement als auch die "unbekannten Instruktionen" (unrecognized opcode) erklären würde.

Wenn man genauer hinsieht, zeigt sich auch, daß KEINER der beiden g++-Aufrufe (weder der für gengenrtl.c noch der für genhooks.c) an dieser Stelle erfolgreich war - die laufen nur (wegen -j2 beim make) parallel und die Ausgaben werden "gemischt".

Das wird am Ende vermutlich darauf hinauslaufen, daß hier irgendwelche Verzeichnisse zusätzlich im Pfad sind (dann drängelt sich der MIPS-Assembler vor) oder auch im Gegenteil darauf, daß die unter Debian fehlen (und der richtige Assembler daher nicht VOR dem für MIPS gefunden wird) - mit dem Ergebnis, daß hier offensichtlich ein falscher Assembler aufgerufen wird. Nur ist das gar nicht so einfach zu testen ... denn innerhalb so eines Builds wird auch heftig an den PATH-Settings geschraubt und wenn man das einfach so in einer Shell aufrufen will, ist es mit Sicherheit am Ende auch der falsche (und nicht der, der da vom g++ verwendet wurde).

Mir fehlt daher auch so ein wenig die Idee, wie man Dich das nun am besten untersuchen lassen könnte (auf anderen Systemen ist das ja offensichtlich KEIN Problem, wobei ich da inzwischen auch nicht mehr soo sicher bin, komme ich noch mal drauf zurück) - man müßte hier wahrscheinlich in das Makefile für den GCC einsteigen und dort zusätzliche Aufrufe einbauen, die einerseits mal den Pfad ausgeben, wie er an dieser Stelle definiert ist und andererseits dann mal alle dort enthaltenen Verzeichnisse danach durchsuchen, wo denn der erste gas zu finden wäre - denn der wird dann vermutlich auch gleich genommen. Aber auch das ist wieder nicht so einfach ... selbst wenn man das mit den "Einzel-Targets" im (Freetz-)Makefile macht, muß man dabei aufpassen, daß die eigenen Änderungen nicht unter die Räder kommen, falls die GCC-Quellen neu ausgepackt werden. Üblicherweise läuft das in Freetz über Patches, die nach dem Auspacken angewandt werden - man müßte also die gewünschten Änderungen als diff-File bereitstellen.

Das ist jedenfalls alles andere als trivial und vielleicht versuchst Du es doch erst einmal damit, daß Du Dir den gas für Deinen Host suchst und das Verzeichnis, in dem der dann liegt, ganz vorne in den Pfad (also die PATH-Variable) explizit einträgst - in der Hoffnung, daß an den Stellen, wo tatsächlich der gas benötigt wird, der am Ende MIPS-Maschinencode ausgibt, dessen Verzeichnis noch davor eingetragen wird im Verlauf des Builds. Zumindest bis zu dem Punkt, wo dann der Cross-Compiler auch erstellt wurde - danach wäre es ja wieder korrekt, wenn MIPS-Code erzeugt wird bei weiteren g++-Aufrufen, denn dann wären ja Binaries für das Ziel zu erstellen.

@gismotro + @Master SaMMy
Seid Ihr Euch sicher, daß Ihr den Build tatsächlich inkl. der Toolchain gemacht habt? Da tritt das beschriebene Problem ja auf und die Einstellung FREETZ_BUILD_TOOLCHAIN=y greift erst dann, wenn noch keine Toolchain-Dateien (also in erster Linie die Compiler und binutils) unterhalb des Freetz-Checkouts existieren (dann wird über Abhängigkeiten der Toolchain-Build dazwischen geschoben). Wenn die schon vorhanden sein sollten, interessiert diese Einstellung i.d.R. gar nicht - damit käme der Build dann aber auch nicht an der Stelle vorbei, wo es hier klemmt (beim Erzeugen des zu verwendenden Cross-Compilers).

 

[gismotro]

Sorry @PeterPawn , ich verstehe leider die Frage nicht.
Bei meinem Test habe ich eine neue VM benutzt und nur den Boxtyp eingestellt.

@ronny_b : Sonst beu dir doch mal eine VM nach diesem HowTo : https://www.ip-phone-forum.de/threa...iedliche-konfigurationen.308030/#post-2387896

 

[ronny_b]

So, ich habe es geschafft! 7.29 ist gebaut und auf der Box.

Das Problem war wohl selbst verschuldet. Da in Debian das Tool

depmod

in

/sbin

liegt, habe ich dieses Verzeichnis einfach an die Variable

PATH

angehängt. Dadurch scheint es an irgend einer Stelle zu diesem Fehler gekommen zu sein. Jetzt habe ich halt zum Kompilieren einen Link

/usr/local/bin/depmod

auf

/sbin/depmod

erstellt.

Wie ich das verstanden habe, sollte das doch auch im Verzeichnis

tools/path

möglich sein, das hat aber leider nicht funktioniert.

Zumindest habe ich es geschafft, Danke vielmals!!

Ronny