[Gelöst] Freetz-NG: Fehler beim Bauen für unterschiedliche Konfigurationen

[gismotro]

Hab das mit ins HowTo übernommen: https://www.ip-phone-forum.de/threa...hiedliche-konfigurationen.308030/post-2387896

 

[fda89]

Warum man lieber auf deutsch stellt? Damit viele Programme ihre Ausgaben auf deutsch machen! Auch Zeit/Datumsformat, Sortierreihenfolge usw

Um eine Konfiguration vollständig zu sichern, muss ich diese Datei (bei 7490 mit FW7.2 müsste das bei mir make/linux/configs/freetz/config-vr9-7490_07.19 sein) also auch immer mit sichern?

Durch die neuen Sourcen hat sich dieser Dateiname geändert. Du musst also nochmals alles auswählen. (Dies hätte durch einen vorherigen pull-request vermieden werden können)

 

[gismotro]

Warum man lieber auf deutsch stellt? Damit viele Programme ihre Ausgaben auf deutsch machen! Auch Zeit/Datumsformat, Sortierreihenfolge usw.
[...]

Ich hab das mal in das aktuelle Freetz-Linux 1.5.8 übernommen.

 

[gismotro]

So sieht es mit dem aktuellen Update aus :

 

[fda89]

Da stimmt der Zeichnsatz nicht, vermutlich vom Terminal. oder von Putty selbst

 

[WileC]

Also ich überlege mir schon länger, wie man Unterverzeichnisse für die jeweiligen Boxen beim Build realisieren könnte... NAND, NOR, oder nach Architektur?!

 

[fda89]

Ich würde den Namen nehmen

 

[Massa]

So, ich habe mal wieder ein wenig Zeit und wollte hier mal wieder weiter berichten.
Ich bin aktuell immer noch nicht in der Lage, ein Freetz-NG Image mit 7.2x-Basis mit von mir gewünschter Funktionalität zu bauen.

Der Build bricht immer mit Fehlermeldungen ab.

Ich habe dann erst einmal mit einer komplett von vorne angefangen - zuerst mit einer "leeren" Konfiguration (d.h. Box 7590 ausgewählt, Kompetenzlevel auf Expert, Firmware 7.2x).
Das hat vollständig gebaut.

Dann habe ich ein wenig mehr "eingebaut" (aber noch lange nicht alles, was ich an Paketen eigentlich möchte) - da kracht es dann bereits wieder und der Build bricht ab.
Wobei ich nicht wirklich erkennen kann, was bzw. wo das jetzt schief läuft?!
Das hier finde ich als Fehler - wobei der Build da trotzdem noch eine ganze Weile weiterläuft, bevor er dann mit einem "build failed" anhält:

mips-unknown-linux-gnu-gcc -Wp,-MD,drivers/regulator/.virtual-platdev.o.d  -nostdinc -isystem /home/freetz/workdir/git.7590-ng_7.2x/toolchain/build/mips_gcc-8.3.0/mips-unknown-linux-gnu/lib/gcc/mips-unknown-linux-gnu/8.3.0/include -I./arch/mips/include -I./arch/mips/include/generated/uapi -I./arch/mips/include/generated  -I./include -Idrivers/char/avm_new/include   -Idrivers/char/avm_net_trace/include   -Idrivers/char/avm_power/include   -Idrivers/char/tffs/include   -Idrivers/isdn/capi_oslib/include   -Inet/avm_pa/include  -Iinclude/generated/lisi -I./arch/mips/include/uapi -I./arch/mips/include/generated/uapi -I./include/uapi -I./include/generated/uapi -Idrivers/char/avm_new/include/uapi   -Idrivers/char/avm_net_trace/include/uapi   -Idrivers/char/avm_power/include/uapi   -Idrivers/char/tffs/include/uapi   -Idrivers/isdn/capi_oslib/include/uapi   -Inet/avm_pa/include/uapi   -include ./include/linux/kconfig.h  -D__KERNEL__ -DVMLINUX_LOAD_ADDRESS=0xffffffff80500000 -DDATAOFFSET=0 -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -Werror-implicit-function-declaration -Wno-format-security -std=gnu89 -fno-PIE -mno-check-zero-division -mabi=32 -G 0 -mno-abicalls -fno-pic -pipe -mno-branch-likely -msoft-float -DGAS_HAS_SET_HARDFLOAT -Wa,-msoft-float -ffreestanding -march=interaptiv -mtune=interaptiv -Wa,-march=interaptiv -Wa,-mtune=interaptiv -Wa,--trap -DTOOLCHAIN_SUPPORTS_VIRT -mdsp -I./arch/mips/include/asm/mach-lantiq -I./arch/mips/include/asm/mach-lantiq/grx500 -I./arch/mips/include/asm/mach-generic -fno-delete-null-pointer-checks -Wno-frame-address -Wno-format-truncation -Wno-format-overflow -Wno-int-in-bool-context -Wno-attribute-alias -O2 -fno-reorder-blocks -fno-tree-ch --param=allow-store-data-races=0 -DCC_HAVE_ASM_GOTO -Wframe-larger-than=1024 -fstack-protector -Wno-unused-but-set-variable -Wno-unused-const-variable -fomit-frame-pointer -fno-var-tracking-assignments -g -Wdeclaration-after-statement -Wno-pointer-sign -Wno-stringop-truncation -fno-strict-overflow -fno-merge-all-constants -fmerge-constants -fno-stack-check -fconserve-stack -Werror=implicit-int -Werror=strict-prototypes -Werror=date-time -Werror=incompatible-pointer-types -Wno-packed-not-aligned -DDEBUG  -DMODULE -mlong-calls  -DKBUILD_BASENAME='"virtual_platdev"'  -DKBUILD_MODNAME='"virtual_platdev"' -c -o drivers/regulator/.tmp_virtual-platdev.o drivers/regulator/virtual-platdev.c
drivers/regulator/virtual-platdev.c:54:1: warning: data definition has no type or storage class
late_initcall(virtual_platdev_init);
^~~~~~~~~~~~~
drivers/regulator/virtual-platdev.c:54:1: error: type defaults to 'int' in declaration of 'late_initcall' [-Werror=implicit-int]
drivers/regulator/virtual-platdev.c:54:1: warning: parameter names (without types) in function declaration
drivers/regulator/virtual-platdev.c:21:19: warning: 'virtual_platdev_init' defined but not used [-Wunused-function]
static int __init virtual_platdev_init(void)
                   ^~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
make[4]: *** [scripts/Makefile.build:311: drivers/regulator/virtual-platdev.o] Error 1
make[3]: *** [scripts/Makefile.build:555: drivers/regulator] Error 2
make[2]: *** [Makefile:1028: drivers] Error 2
make[2]: *** Waiting for unfinished jobs....

(@PeterPawn: wie hast Du denn das Log eingefärbt? Ich habe auf "Code=rich" geschaltet - bringt aber leider nichts)

Die funktionierende "Minimal"-Konfig sowie die nicht mehr funktionierende Konfig und das komplette Log habe ich angehängt...[/Code]

 

[fda89]

Hast du die Konfiguration des Kernels geändert? "git status"
Wenn du im freetz-menuconfig nur "1 parallelen" Prozess zulässt ist der Fehler einfacher am Ende zu sehen

 

[PeterPawn]

@Massa:

Das ist rot.

Wenn Du tatsächlich diese Schreibweise genutzt hast (also nur das erste Zeichen groß - das "dangling end tag" vor den Attachments deutet ja auch darauf hin, das wurde ggf. von Xenforo eingefügt), weiß ich nicht, wie der Parser von Xenforo darauf reagiert.

Einfach über die drei Punkte im WYSIWYG-Editor das passende Tag syntaktisch korrekt einbauen lassen, wenn man's nicht genau weiß - danach kann man dann auch darin die passenden Text-Attribute über die Editor-Icons setzen.

Ansonsten sieht der Fehler halt "komisch" aus, weil da - wegen der ganzen Einstellungen zu den "Warnungen", die auch noch als Fehler gewertet werden sollen - das "late_initcall" als Prototyp angesehen wird und nicht als Funktionsaufruf. Definiert ist das "late_initcall()" entweder in der "include/linux/init.h" oder in der "include/linux/module.h" - die kann nun entweder direkt eingeschlossen werden von der "./drivers/regulator/virtual-platdev.c" oder über eine andere Datei, die dort "inkludiert" wird.

Schaut man sich die Datei an, sieht man, daß da zweimal die "linux/platform_device.h" aufgeführt ist als Include-File - vielleicht sollte einer davon in Wirklichkeit eine der beiden o.a. Dateien sein. Ich weiß auch nicht (und habe keine Lust danach zu suchen), warum das bei den von AVM bereitgestellten Paketen bisher nicht auffällt - ich rate mal ganz wild und sage, daß man dort entweder andere Einstellungen für die Compiler-Warnungen verwendet oder beim Patchen des "vanilla kernel" für die OSS-Pakete irgendetwas schiefgelaufen ist.

Was mich irritiert ist die Tatsache, daß das wohl erst mit dem Cross-Compiler (wohl beim Kernel-Build) für die Box auftritt (was die GCC-Version des Build-Hosts ja eigentlich aus der Rechnung nimmt) und ansonsten noch von niemandem (oder ich habe das verpaßt) gemeldet wurde.

Entweder die bauen alle ohne den Kernel (oder der ist schon vorher übersetzt, als die Quellen noch anders aussahen, wobei das mit der "virtual-platdev.c" schon länger so wäre m.W.), weil ein "replace kernel" ja m.W. auch in Freetz-NG noch nicht möglich ist, weil sich niemand der Mühe unterzieht, ein Skript/Programm zu schreiben, was aus der "bootcore"-Kernel und dem eigenen eine passende Datei zum Start der GRX-Boxen zimmert (das Format der Kernel-Datei ist halt ein anderes, weil es in Wirklichkeit zwei Kernel sind, die jeweils auch noch einen eigenen (Adam2/EVA-)Header haben).

Um hier erst mal weiter zu kommen, kann man die erwähnte C-Datei halt so patchen (lassen), daß einer der beiden "platform_device.h"-Abrufe stattdessen die "init.h" benutzt (die müßte passen - wenn nicht (ich habe nicht weiter hineingesehen), dann eben die andere) und dann schauen, ob es nicht doch bei weiteren Dateien dann dasselbe Problem gibt. Sollte das so sein, wäre es ggf. zu erwägen, die "init.h" in die "platform_device.h" einzubauen und damit für mehrere Dateien das Problem zu erschlagen. Ich habe auch keine Ahnung, ob diese Datei (das (C) ist Intel 2018) jetzt zu den Patches für die GRX-SoCs gehört (was ich vermute) oder zum "vanilla kernel" - auch das müßte ich erst selbst recherchieren.

Die Alternative wäre das Herunterdrehen von Compiler-Warnungen - wobei ich auch da nicht genau sagen könnte, was notwendig wäre, damit das nicht mehr auftritt. Ich würde also erst mal die eine Zeile patchen und dann warten, ob es bei weiteren Stellen auch noch Probleme gibt, die auf zu hohen Erwartungen an die syntaktische Korrektheit der Quellen zurückzuführen wären. Dann müßte man sich ggf. etwas anderes überlegen.

Und nur um das noch einmal zu erwähnen ... ich habe auch in den 07.21-Quellen von AVM bisher noch nichts finden können (vielleicht bin ich ja auch nur zu doof dazu), womit man die Strukturen in der "avm_kernel_config" nachbauen könnte, wenn man einen eigenen Kernel verwenden wollte und auch ein passendes "mksquashfs" für das von AVM geänderte Format des SquashFS-Dateisystems, habe ich nirgendwo gesehen.

 

[fda89]

Entweder die bauen alle ohne den Kernel (oder der ist schon vorher übersetzt, als die Quellen noch anders aussahen, wobei das mit der "virtual-platdev.c" schon länger so wäre m.W.), weil ein "replace kernel" ja m.W. auch in Freetz-NG noch nicht möglich ist, weil sich niemand der Mühe unterzieht, ein Skript/Programm zu schreiben, was aus der "bootcore"-Kernel und dem eigenen eine passende Datei zum Start der GRX-Boxen zimmert (das Format der Kernel-Datei ist halt ein anderes, weil es in Wirklichkeit zwei Kernel sind, die jeweils auch noch einen eigenen (Adam2/EVA-)Header haben).

Das können nur sehr wenige, und der der es könnte hat bestimmt keine Lust.
Ein Kernel wird auf jeden Fall gebaut wenn replace-kernel aktiviert oder mindestens 1 Modul ausgewählt ist

 

[PeterPawn]

Das können sicherlich ein paar Leute mehr ... nur haben die wahrscheinlich "den Bedarf" dafür nicht. Bei mir gilt auf alle Fälle letzteres - daher auch die Idee, den AVM-Kernel beim TUN-Device "live" zu patchen, anstatt da auf einen selbstgebackenen Kernel zu setzen, wo die Patches schon beim Kompilieren eingepreist werden.

Ich habe ja letztens auch mal zumindest die Toolchain und ein minimales Images mit NG bauen lassen - nur ist das schon wieder Geschichte und daher kann ich auch nicht einfach mal so einen neuen Build anwerfen, wo dann auch die Kernel-Quellen mit übersetzt werden - ich weiß also nicht, ob das generell dann auftritt, wenn man die 07.21-Quellen übersetzen lassen will.

Ich denke nur, das wäre dann ggf. auch schon früher aufgefallen (der Inhalt der "virtual-platdev.c" ist schon seit frühen 07.19-Ständen derselbe und sollte eigentlich spätestens dann übersetzt werden, wenn man Treiber für USB-Cardreader oder andere Geräte mit seriellem Interface bauen lassen will) und daher auch schon früher berichtet worden.

Wobei mir da noch ein Satz/eine Bitte in Richtung @Massa einfällt: Es wäre schön, wenn Du anstelle der "ausführlichen .config" jeweils die komprimierte Form anhängen könntest (gerne auch zusätzlich, wenn's unbedingt die andere auch sein soll) - die ist deutlich übersichtlicher und gerade bei den ganzen Änderungen der FREETZ-Symbole durch @cuma, blicken außer ihm wohl nur noch wenige durch, was den Umfang einer solchen "kompletten" Datei anbelangt - ich gehöre da definitiv nicht dazu, weil mir dafür Interesse und Zeit fehlen.

Eine ".config.compressed" für ein Minimal-Image einer 7590 (das ist bei NG die Standardeinstellung) hat u.U. gar keinen Inhalt (was besonders schnell zu überblicken ist) und im Idealfall ist auch nur die geänderte Einstellung für "Experte" zu sehen.

 

[fda89]

Ich hab auch keinen Bedarf, ein Raspberry kann VPN eh schneller und stabiler, dazu hat der keine Problem mit iptables/netfilter und kann sogar masquerading ohne Geschindigkeitsverluste. Der 4.9er Kernel der 7590 braucht offenbar keinen Patch mehr / hat keine BUGON
Die 7.21 Quellen lassen sich mit Fedora auf jeden Fall bauen, ich hab autofs, nfs, cifs, etc im Image

 

[PeterPawn]

@Massa:
Keine Ahnung, warum da bei Dir überhaupt "CONFIG_REGULATOR_VIRTUAL_CONSUMER_PLATDEV" gesetzt ist, wenn Du "frisch" gestartet bist. Solange man an der Kernel-Konfiguration dann nichts ändert, sollte die Datei "virtual_platdev.c" gar nicht angefaßt werden, weil sie im "Makefile" nur bei dieser Option mitgebaut wird:

[...]
obj-$(CONFIG_REGULATOR) += core.o dummy.o fixed-helper.o helpers.o devres.o
obj-$(CONFIG_OF) += of_regulator.o
obj-$(CONFIG_REGULATOR_FIXED_VOLTAGE) += fixed.o
obj-$(CONFIG_REGULATOR_VIRTUAL_CONSUMER) += virtual.o
obj-$(CONFIG_REGULATOR_VIRTUAL_CONSUMER_PLATDEV) += virtual-platdev.o
obj-$(CONFIG_REGULATOR_USERSPACE_CONSUMER) += userspace-consumer.o
[...]

Deine Kernel-Konfiguration findest Du unter "source/kernel/ref-grx5-7590_07.20/linux-4.9/.config" und da sollte das erwähnte Symbol auf "is not set" stehen ... dann sollte eben auch die Datei gar nicht erst übersetzt werden.

Wobei die auch nicht zu den Quellen des "vanilla kernel" gehört: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/regulator?h=v4.9.243 - sondern vermutlich tatsächlich zu den Patches für die GRX-SoCs. Um DAS dann wieder genauer zu ermitteln (weil AVM ja nicht Basis-Code + Patches liefert, sondern nur die fertig gepatchten Quellen), müßte man erst wieder andere Quellen für die Intel/Lantiq-Patches für die GRX-Boxen auftun/untersuchen.

Bleibt die Frage, wie bei Dir da ein "y" in die ".config" kommt - denn das (oder ein "m") müßte da enthalten sein, wenn das "make" diese Datei zu den "Zielen" hinzugefügt hat.

 

[Massa]

Hast du die Konfiguration des Kernels geändert? "git status"

Du hast Recht - "git status" zeigt mir, dass ich noch eine veränderte Kernel-Konfiguration habe / hatte - ich hatte gedacht, dass ein "make distclean" das auch zurückrollen würde (aber dummerweise nicht kontrolliert).

Nachdem ich die Datei wieder restored habe (die veränderte Datei habe ich mal hier angehängt - vielleicht kann jemand was damit anfangen...), lief der Build durch - und danach dann auch mit stark erweiterter Konfiguration
Ich würde gerne mal mit aktivem Watchdog probieren, ob meine Box / Konfiguration auch vom Reboot-Problem betroffen ist - reicht es dazu aus, den Parameter "FREETZ_PATCH_DISABLE_AVM_WATCHDOG" in der .config von Hand auszukommentieren?
Was mich auch noch gewundert hat: es wird keine ".in-memory"-Datei mehr erzeugt - ist das Absicht?

Einfach über die drei Punkte im WYSIWYG-Editor das passende Tag syntaktisch korrekt einbauen lassen, wenn man's nicht genau weiß - danach kann man dann auch darin die passenden Text-Attribute über die Editor-Icons setzen.

Also muss man die Farben sozusagen "von Hand" nachfärben?
Ich hatte gehofft, der Parser erkennt eine "make"-Ausgabe und färbt das automatisch ein...

Die angehängte Kernel-Konfig stammt noch von meinen letzten Versuchen, über "make kernel-menuconfig" alle möglichen Module auszuwählen, damit ich alle erwische, die beim Bau meines Images benötigt werden.
Inzwischen scheint das ja wieder unproblematischer und ohne "make kernel-menuconfig" zu gehen?!

Wobei mir da noch ein Satz/eine Bitte in Richtung @Massa einfällt: Es wäre schön, wenn Du anstelle der "ausführlichen .config" jeweils die komprimierte Form anhängen könntest (gerne auch zusätzlich, wenn's unbedingt die andere auch sein soll) - die ist deutlich übersichtlicher und gerade bei den ganzen Änderungen der FREETZ-Symbole durch @cuma, blicken außer ihm wohl nur noch wenige durch, was den Umfang einer solchen "kompletten" Datei anbelangt - ich gehöre da definitiv nicht dazu, weil mir dafür Interesse und Zeit fehlen.

Eine ".config.compressed" für ein Minimal-Image einer 7590 (das ist bei NG die Standardeinstellung) hat u.U. gar keinen Inhalt (was besonders schnell zu überblicken ist) und im Idealfall ist auch nur die geänderte Einstellung für "Experte" zu sehen.

O.K. - das mache ich in Zukunft.
Wenn ich eine (ältere) .config in mein Build-Verzeichnis reinkopiere und dann ein "make oldconfig" mache, wird die dann (neu) erzeugt?

 

[fda89]

ich hatte gedacht, dass ein "make distclean" das auch zurückrollen würde (aber dummerweise nicht kontrolliert).

Nein, aber hier sind ein paar Git-Befehle um alles zurückzusetzen https://github.com/Freetz-NG/freetz-ng/blob/master/README.md#readme . Das ist erreichbar über https://freetz-ng.github.io/ >> README (deutsch: "lies mich" )

Du kannst remove-untrustedd auswählen, dann kann disable-watchdog deaktiviert werden. Oder diese Zeile löschen und danach im menuconfig die Option deaktivieren: https://github.com/Freetz-NG/freetz-ng/blob/master/config/ui/firmware.in#L469

 

[Massa]

@fda89: Danke - das werde ich bei Gelegenheit versuchen!

 

[WileC]

Ich spiele derzeit auch wieder etwas herum, diesmal mit freetz-ng ... Hier geht mein "make" nicht durch und ich komme trotz Suchmaschine nicht auf die Fehlerlösung..

make -j2  -C /home/freetz/freetz-ng-7590/source/toolchain-mips_gcc-8.3.0_uClibc-1.0.37-nptl_kernel-4.9/uClibc-ng-1.0.37 \
         LOCALE_DATA_FILENAME=uClibc-locale-be-32-de_DE-en_US.tar.gz MIPS_CUSTOM_ARCH_CPU_CFLAGS="-march=34kc -mtune=34kc"  V=1 \
        PREFIX=/home/freetz/freetz-ng-7590/source/toolchain-mips_gcc-8.3.0_uClibc-1.0.37-nptl_kernel-4.9/uClibc_dev/ \
        DEVEL_PREFIX=/usr/ \
        RUNTIME_PREFIX=/home/freetz/freetz-ng-7590/source/toolchain-mips_gcc-8.3.0_uClibc-1.0.37-nptl_kernel-4.9/uClibc_dev/ \
        HOSTCC="gcc  -D_GNU_SOURCE -fno-stack-protector -U_GNU_SOURCE -fno-strict-aliasing" headers \
        install_headers
make[1]: Verzeichnis „/home/freetz/freetz-ng-7590/source/toolchain-mips_gcc-8.3.0_uClibc-1.0.37-nptl_kernel-4.9/uClibc-ng-1.0.37“ wird betreten
make -C extra/locale locale_headers
gcc  -D_GNU_SOURCE -fno-stack-protector -U_GNU_SOURCE -fno-strict-aliasing ../../extra/locale/gen_locale.c  -o ../..//extra/locale/gen_locale    -Os  -D_GNU_SOURCE -I../..//extra/locale
In file included from ../../extra/locale/gen_locale.c:13:
../../extra/locale/c8tables.h:1:1: error: unknown type name 'could'
    1 | could not find a UTF8 locale ... please enable en_US.UTF-8
      | ^~~~~
../../extra/locale/c8tables.h:1:11: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'find'
    1 | could not find a UTF8 locale ... please enable en_US.UTF-8
      |           ^~~~
../../extra/locale/c8tables.h:1:11: error: unknown type name 'find'
../../extra/locale/gen_locale.c: In function 'do_locale_names':
../../extra/locale/gen_locale.c:203:64: warning: format '%d' expects argument of type 'int', but argument 3 has type 'long int' [-Wformat=]
  203 |    fprintf(ofp, "#define __LOCALE_DATA_AT_MODIFIERS_LENGTH\t\t%d\n",
      |                                                               ~^
      |                                                                |
      |                                                                int
      |                                                               %ld
  204 |      i + (at_strings_end - at_strings));
      |      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |        |
      |        long int
../../extra/locale/gen_locale.c:205:68: warning: format '%d' expects argument of type 'int', but argument 3 has type 'long int' [-Wformat=]
  205 |    fprintf(ofp, "static const unsigned char __locale_at_modifiers[%d] = {",
      |                                                                   ~^
      |                                                                    |
      |                                                                    int
      |                                                                   %ld
  206 |      i + (at_strings_end - at_strings));
      |      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |        |
      |        long int
../../extra/locale/gen_locale.c:227:42: error: 'lc_names' undeclared (first use in this function)
  227 |     fprintf(ofp, "#define __%s\t\t%d\n", lc_names[i], i);
      |                                          ^~~~~~~~
../../extra/locale/gen_locale.c:227:42: note: each undeclared identifier is reported only once for each function it appears in
make[2]: *** [Makefile.in:143: ../..//extra/locale/gen_locale] Error 1
make[1]: *** [Makefile.in:185: headers] Fehler 2
make[1]: Verzeichnis „/home/freetz/freetz-ng-7590/source/toolchain-mips_gcc-8.3.0_uClibc-1.0.37-nptl_kernel-4.9/uClibc-ng-1.0.37“ wird verlassen
make: *** [toolchain/make/target/uclibc/uclibc.mk:130: /home/freetz/freetz-ng-7590/source/toolchain-mips_gcc-8.3.0_uClibc-1.0.37-nptl_kernel-4.9/uClibc-ng-1.0.37/.configured] Fehler 2
freetz@vm-freetz-linux:~/freetz-ng-7590$

Ich nutze die selbe Buildumgebung wie für Freetz auf einer Ubuntu 20.04.1 VM ... die freetz-ng prerequisites habe ich angewandt...

Vielen Dank schonmal...

 

[alis123]

Hast du dieses mal versucht : https://www.ip-phone-forum.de/threa...on-der-benötigten-pakete.309681/#post-2417045

danach muss, zu mindestens bei mir, das Verzeichnis gelöscht und neu angelegt werden.

 

[WileC]

Hallo @alis123

Danke für den Hinweis, hat geklappt... hatte mir extra nochmal die PREREQUISITES durchgelesen und ausprobiert.. ging nicht... dann habe ich mal eine FOS 7.10 und eine FOS 7.21 gebaut -> ging problemlos durch.. bei der FOS 7.25 hat er gestreikt ... nach deinem Hinweis klappt nun auch der Bau einer FOS 7.25 für die 7590.

Danke.