Build error: unknown pseudo-op: `.module'

[JohnDoe42]

Hallo zusammen,

mit der .config im Anhang bekomme ich mit dem aktuellen Trunk diesen Bau-Fehler:

gcc -Wp,-MD,scripts/.kallsyms.d -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 -fomit-frame-pointer -std=gnu89   -I/home/ralf/GitHubs/freetz-ng/source/kernel/ref-vr9-7490_07.27/linux-3.10/tools/include  -o scripts/kallsyms scripts/kallsyms.c  
{standard input}: Assembler messages:
{standard input}:4: Error: unknown pseudo-op: `.module'
{standard input}:5: Error: unknown pseudo-op: `.module'
make[5]: *** [scripts/Makefile.build:309: scripts/mod/empty.o] Fehler 1
make[4]: *** [scripts/Makefile.build:455: scripts/mod] Fehler 2
make[4]: *** Auf noch nicht beendete Prozesse wird gewartet …
make[3]: *** [Makefile:524: scripts] Fehler 2
make[2]: *** [GNUmakefile:109: vmlinux.eva_pad] Fehler 2
make[1]: *** [make/kernel/kernel.mk:230: source/kernel/ref-vr9-7490_07.27/linux-3.10/arch/mips/boot/vmlinux.eva_pad] Beendet
make: *** [Makefile:46: envira] Beendet

Ich habe die Versionen von gcc und g++ verglichen (beide Ubuntu 9.4.0-1ubuntu1~20.04.1) und binutils mal auf den neuesten Stand gebracht. Leider alles erfolglos.
Hat jemand einen Tip, woran das liegen könnte? Ist das eventuell auch auf die neue Toolchain basierend auf Ubunto 20.04 zurück zu führen ? Falls ja, würde mich das wundern, da mein Build-System ein solches ist.
Grüße und Dank im Voraus

JD.

 

[PeterPawn]

Das sieht so aus, als hätte make kein kallsyms-Tool gefunden und jetzt wird versucht, sich nachträglich eines zu bauen.

Unklar ist mir aber, wieso er hier (wo doch FREETZ_REPLACE_KERNEL gar nicht gesetzt ist und dann bräuchte man auch keinen Kernel linken, wozu man dann wieder kallsyms benötigen würde) überhaupt auf den Gedanken verfällt, einen neuen Kernel bauen zu wollen. Die fünf in der Konfiguration auftauchenden FREETZ_MODULE_* sollten jedenfalls auch nicht zur Notwendigkeit führen, einen neuen Kernel linken zu wollen.

VERMUTLICH ist dieser Versuch mit dem Linker tatsächlich unnötig und daher wurde (basierend auf den Abhängigkeiten, die in den diversen Makefiles und von denen wieder inkludierten Dateien beschrieben sind) wohl auch das "goal" (https://www.kernel.org/doc/Documentation/kbuild/makefiles.txt - Punkt 3) mit dem Namen hostprogs-y, in dem die Namen der zu erstellenden Tools versammelt sind, nicht ausgeführt.

Wie immer bei so unklarem Fehlerbild die Empfehlung, alle Schritte zu serialisieren (max. Jobs = 1) und vom (frischen) Build mittels fmake (siehe Freetz-NG-Verzeichnis) ein Protokoll anfertigen zu lassen, daß man dann hier einstellt. Solche "Ausschnitte" (wie oben gezeigt) bieten immer nur den Blick auf die LETZTEN Fehler, die bei einem Build aufgetreten sind und alles, was ggf. schon davor zu einem Problem wurde (auch wenn der Build dabei noch nicht abgebrochen wurde), sieht man daran nicht (mehr).

 

[JohnDoe42]

Hallo zusammen,

@PeterPawn :

Danke für die sachdienlichen Hinweise. fmake hatte ich mir angesehen, da ich mich da erst einarbeiten müßte, habe ich allerdings diesen Lösungsansatz zugunsten von Zeit erst mal verschoben und bin "oldschool" vorgegangen, indem ich ein "leeres" image nach und nach mit Paketen bzw. Patches versehe.
Ergebnis:
Ich glaube, dass der springende Punkt

FREETZ_REMOVE_UPNP=y

ist. Darin unterscheidet sich zumindest ein älteres, noch kompilierbares Image von meinem Versuch von oben, sprich: Wenn ich dieses Removal auswähle, stosse ich auf den o.g. Build-Fehler. D.h. das kompilier- und lauffähige ältere Image hat dieses Removal. Wenn ich das gleiche Removal im aktuellen Trunk auswähle, tritt der o.g. Fehler auf. Es sei nochnmal expliziert angemerkt, dass ich kein Replace Kernel ausgewählt habe, wie PeterPawn schon richtig bemerkt hat.
Evtl. kann das ja jemand vorbehaltlich Zeit und Lust verifizieren.
Grüße

JD.