[Problem] Freetz-NG: Fehler beim Bauen für unterschiedliche Konfigurationen

Massa

Mitglied
Mitglied seit
18 Dez 2004
Beiträge
200
Punkte für Reaktionen
4
Punkte
18
Hallo zusammen,

ich habe jetzt schon eine ganze Weile das Problem, dass meine Freetz-NG Builds nicht mehr durchlaufen.
Zuerst waren es immer Kernel-Module / Abhängigkeiten die dann nicht erfüllt waren und die ihm dann irgendwann gefehlt hatten.
Da dachte ich, naja - dann mach' ich halt mal wieder Tabula Rasa und baue komplett von vorne (make distclean, make kernel-dirclean, make tools-dirclean).

Aber leider hat das das Problem nur verschärft - jetzt baut er noch nicht einmal mehr die toolchain und bricht da mit Fehlermeldungen ab:
Code:
/home/freetz/workdir/git.7590-ng_7.20/toolchain/build/mips_gcc-8.3.0_uClibc-1.0.15-nptl_kernel-4.9/mips-linux-uclibc/bin/mips-linux-uclibc-g++  -I/home/freetz/workdir/git.7590-ng_7.20/source/toolchain-mips_gcc-8.3.0_uClibc-1.0.15-nptl_kernel-4.9/gcc-8.3.0/libcpp -I. -I/home/freetz/workdir/git.7590-ng_7.20/source/toolchain-mips_gcc-8.3.0_uClibc-1.0.15-nptl_kernel-4.9/gcc-8.3.0/libcpp/../include -I/home/freetz/workdir/git.7590-ng_7.20/source/toolchain-mips_gcc-8.3.0_uClibc-1.0.15-nptl_kernel-4.9/gcc-8.3.0/libcpp/include  -march=34kc -mtune=34kc -msoft-float -Os -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/git.7590-ng_7.20/source/toolchain-mips_gcc-8.3.0_uClibc-1.0.15-nptl_kernel-4.9/gcc-8.3.0/libcpp -I. -I/home/freetz/workdir/git.7590-ng_7.20/source/toolchain-mips_gcc-8.3.0_uClibc-1.0.15-nptl_kernel-4.9/gcc-8.3.0/libcpp/../include -I/home/freetz/workdir/git.7590-ng_7.20/source/toolchain-mips_gcc-8.3.0_uClibc-1.0.15-nptl_kernel-4.9/gcc-8.3.0/libcpp/include   -c -o charset.o -MT charset.o -MMD -MP -MF .deps/charset.Tpo /home/freetz/workdir/git.7590-ng_7.20/source/toolchain-mips_gcc-8.3.0_uClibc-1.0.15-nptl_kernel-4.9/gcc-8.3.0/libcpp/charset.c
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 icelake-server cascadelake bonnell atom silvermont slm goldmont goldmont-plus tremont knl knm x86-64 eden-x2 nano nano-1000 nano-2000 nano-3000 nano-x2 eden-x4 nano-x4 k8 k8-sse3 opteron opteron-sse3 athlon64 athlon64-sse3 athlon-fx amdfam10 barcelona bdver1 bdver2 bdver3 bdver4 znver1 znver2 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 icelake-server cascadelake bonnell atom silvermont slm goldmont goldmont-plus tremont knl knm intel x86-64 eden-x2 nano nano-1000 nano-2000 nano-3000 nano-x2 eden-x4 nano-x4 k8 k8-sse3 opteron opteron-sse3 athlon64 athlon64-sse3 athlon-fx amdfam10 barcelona bdver1 bdver2 bdver3 bdver4 znver1 znver2 btver1 btver2 generic native
make[3]: *** [Makefile:224: charset.o] Error 1
make[3]: Leaving directory '/home/freetz/workdir/git.7590-ng_7.20/source/toolchain-mips_gcc-8.3.0_uClibc-1.0.15-nptl_kernel-4.9/gcc-8.3.0-target/build-x86_64-pc-linux-gnu/libcpp'
make[2]: *** [Makefile:2743: all-build-libcpp] Error 2
Und das egal ob ich für eine 7590 oder für eine 7490 bauen möchte und egal ob für 7.1x oder 7.2x Firmware-Version.

Das ganze unter Ubuntu 20.01 mit aktuellem Stand...

Hat da jemand eine Idee, was da schief sein könnte?
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,255
Punkte für Reaktionen
1,088
Punkte
113
Da wird offensichtlich eine Toolchain für die falsche Architektur gebaut. Ein "-march=34kc" oder "-mtune=34kc" ist zwar korrekt, wenn es um das Übersetzen von Programmen FÜR die FRITZ!Box geht - aber hier wird wohl gerade - auch wenn der "Kontext" nun wirklich wieder einmal "zum Heulen" ist, warum nimmst Du/nehmt Ihr (denn das gilt auch für viele andere) da nicht einfach mal "fmake" und erstellt ein "richtiges" Protokoll? - erst dieser Compiler gebaut (so wäre das aus den Pfadnamen zu schließen), der danach dann für die Übersetzung der Quellen FÜR die FRITZ!Box benutzt werden soll und der dann diese Optionen auch kennen sollte.

Oder Du hast die Option "Toolchain für Target erzeugen" (oder so ähnlich und ich weiß nicht mal genau, ob die unter Freetz-NG auch enthalten ist) aktiviert (die Unsicherheit diesbezüglich ist eben den fehlenden Infos geschuldet) - dann sollte es erst mal reichen, diese wieder zu deaktivieren, denn mit der Toolchain auf einer FRITZ!Box können/wollen nur die Allerwenigsten auch etwas anfangen ... das ist schon "sehr speziell", auch weil es da diverse andere Hilfsmittel wie "automake" oder "autoconf" nicht gibt und man schon wissen muß, wie man Compiler und Linker "von Hand" aufruft. Man kann also (mit Fug und Recht) behaupten, daß nur eine Handvoll Leute diese Option (bzw. das Ergebnis einer Übersetzung mit dieser Option) tatsächlich brauchen können.
 

fda89

Mitglied
Mitglied seit
31 Aug 2020
Beiträge
217
Punkte für Reaktionen
41
Punkte
28
Keine Ahnung ob es ne Toolchain fürs target gibt, hab ich nie verwendet oder verändert..
Was aber auffällt ist dass der "neue" gcc8 verwendet wird, vielleicht passt da was nicht.
Oder wegen uClibc-1.0.15. All *anderen* Versionen von Freetz *ersetzen* die AVM Version. Nur die 1.0.15 landet in /usr/lib/freetz/ und AVM nutz die unveränderte uclibc/glibc/musl
Möglich ist auch dass ne Target-toolchain für arm/x86 erstellt werden soll, keine Ahnung ob das implementiert ist
In dem Kontext kann es aber auch alles andere sein
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,255
Punkte für Reaktionen
1,088
Punkte
113
Keine Ahnung ob es ne Toolchain fürs target gibt
Gibt es aber: https://github.com/Freetz/freetz/blob/master/config/ui/toolchain.in#L495 - zumindest staune ich mal, daß Dir das nicht geläufig ist. Es gäbe auch eine (kurze) Hilfe/Anleitung dazu: https://freetz.github.io/wiki/help/howtos/development/create_cross-compiler_toolchain.html - ich weiß aber gerade auch nicht, wie alt und wie aktuell die noch ist.

In dem Kontext kann es aber auch alles andere sein
Na ja ... da fehlt zwar tatsächlich viel "Kontext", aber ein "make", was am Ende im Verzeichnis "source/toolchain-mips_gcc-8.3.0_uClibc-1.0.15-nptl_kernel-4.9/gcc-8.3.0-target/build-x86_64-pc-linux-gnu/libcpp" herumturnt:
Code:
make[3]: Leaving directory '/home/freetz/workdir/git.7590-ng_7.20/source/toolchain-mips_gcc-8.3.0_uClibc-1.0.15-nptl_kernel-4.9/gcc-8.3.0-target/build-x86_64-pc-linux-gnu/libcpp'
bietet nun wenig Anlaß zu einer Vermutung, daß es irgendetwas mit einem ARM-System zu tun haben könnte. Wo sieht man in dem (zugegebermaßen eher spärlichen) Log-Ausschnitt etwas in dieser Richtung? "x86_64" kann ich noch sehen und "mips" auch noch - von "arm" aber keine Spur. Da soll (nach meinem Verständnis jedenfalls) ein GCC 8.3.0 für einen Build mit einer MIPS-Box als Ziel erstellt werden und das auf einem System, was x86_64-Architektur verwendet - also letztlich ein Cross-Compiler, der auf einem 64-Bit-Intel-System den Code für eine MIPS-Plattform erzeugen kann.

Wobei der ganze Teil, der überhaupt mit dem GCC 8 arbeitet, ja ohnehin von Dir stammt und nur unter Freetz-NG verfügbar ist:
Code:
$ diff -u freetz/config/ui/toolchain.in freetz-ng/config/ui/toolchain.in
--- freetz/config/ui/toolchain.in       2020-09-30 17:48:43.467866586 +0200
+++ freetz-ng/config/ui/toolchain.in    2020-09-26 12:20:32.831349051 +0200
@@ -8,18 +8,44 @@
                Download Toolchain, build toolchain

        config FREETZ_DOWNLOAD_TOOLCHAIN
-               bool "Download and use precompiled toolchains"
+               bool "Use precompiled toolchains (x86 only)"
+               depends on    FREETZ_REAL_DEVELOPER_ONLY__DLTC || FREETZ_AVM_VERSION_06_9X_MAX
+               depends on !(!FREETZ_REAL_DEVELOPER_ONLY__DLTC && FREETZ_SYSTEM_TYPE_IPQ40xx)
+               depends on !(!FREETZ_REAL_DEVELOPER_ONLY__DLTC && FREETZ_SYSTEM_TYPE_PUMA6)
+               depends on !(!FREETZ_REAL_DEVELOPER_ONLY__DLTC && FREETZ_SYSTEM_TYPE_QCA956x)
+               depends on !(!FREETZ_REAL_DEVELOPER_ONLY__DLTC && FREETZ_SYSTEM_TYPE_IKS_VX185)
+               depends on !FREETZ_SEPARATE_AVM_UCLIBC
+
+       config FREETZ_BUILD_TOOLCHAIN
+               bool "Build own toolchains (4GB diskspace)"
+
+endchoice # "Toolchains" #
+
+choice
+       prompt "Toolchain version"
+       depends on FREETZ_DOWNLOAD_TOOLCHAIN
+       default FREETZ_DOWNLOAD_TOOLCHAIN_13747
+       help
+               Chose version of precompiled toolchains
+
+       config FREETZ_DOWNLOAD_TOOLCHAIN_13747
+               bool "r13747"
                depends on FREETZ_AVM_VERSION_06_9X_MAX
                depends on !FREETZ_SYSTEM_TYPE_IPQ40xx
                depends on !FREETZ_SYSTEM_TYPE_PUMA6
                depends on !FREETZ_SYSTEM_TYPE_QCA956x
+               help
+                       Uses r13747 (and some r14612)

-       config FREETZ_BUILD_TOOLCHAIN
-               bool "Build own toolchains (requires 4GB diskspace)"
+       config FREETZ_DOWNLOAD_TOOLCHAIN_15256
+               bool "r15256"
+               depends on FREETZ_REAL_DEVELOPER_ONLY__DLTC
+               help
+                       Use r15256 (and some r13747)

-endchoice # "Toolchains" #
+endchoice # "Toolchain version" #

-comment "Kernel toolchain options ----------------------------------"
+comment "Kernel toolchain options ----------------------------------------"

 config FREETZ_KERNEL_BINUTILS_2_18_DEFAULT
        bool
@@ -35,7 +61,11 @@
        default y
 config FREETZ_KERNEL_BINUTILS_2_25_DEFAULT
        bool
-       depends on FREETZ_AVM_GCC_5_MIN   && FREETZ_AVM_VERSION_07_0X_MIN
+       depends on FREETZ_AVM_GCC_5
+       default y
+config FREETZ_KERNEL_BINUTILS_2_31_DEFAULT
+       bool
+       depends on FREETZ_AVM_GCC_8
        default y

 choice
@@ -44,6 +74,7 @@
        default FREETZ_KERNEL_BINUTILS_2_22 if FREETZ_KERNEL_BINUTILS_2_22_DEFAULT
        default FREETZ_KERNEL_BINUTILS_2_24 if FREETZ_KERNEL_BINUTILS_2_24_DEFAULT
        default FREETZ_KERNEL_BINUTILS_2_25 if FREETZ_KERNEL_BINUTILS_2_25_DEFAULT
+       default FREETZ_KERNEL_BINUTILS_2_31 if FREETZ_KERNEL_BINUTILS_2_31_DEFAULT

        config FREETZ_KERNEL_BINUTILS_2_18
                bool "binutils-2.18"
@@ -65,7 +96,7 @@

        config FREETZ_KERNEL_BINUTILS_2_24
                bool "binutils-2.24"
-               depends on FREETZ_AVM_GCC_4_6_MIN
+               depends on FREETZ_AVM_GCC_4_6_MIN && FREETZ_AVM_GCC_5_MAX
                # depends on any kernel version
                depends on FREETZ_KERNEL_BINUTILS_2_24_DEFAULT || (FREETZ_BUILD_TOOLCHAIN || FREETZ_DL_TOOLCHAIN_OVERRIDE)

@@ -74,15 +105,21 @@
                # starting with version 2.25 binutils support o32 FPXX
                # gcc versions up to 4.9.3 however do not pass the required -m(hard|soft)-float flags to the assembler
                # this is the reason for the gcc-4.9 dependency below
-               depends on FREETZ_AVM_GCC_4_9_MIN
+               depends on FREETZ_AVM_GCC_4_9_MIN && FREETZ_AVM_GCC_5_MAX
                # depends on any kernel version
                depends on FREETZ_KERNEL_BINUTILS_2_25_DEFAULT || (FREETZ_BUILD_TOOLCHAIN || FREETZ_DL_TOOLCHAIN_OVERRIDE)

        config FREETZ_KERNEL_BINUTILS_2_26
                bool "binutils-2.26.1"
-               depends on FREETZ_AVM_GCC_4_9_MIN
+               depends on FREETZ_AVM_GCC_4_9_MIN && FREETZ_AVM_GCC_5_MAX
                # depends on any kernel version
                depends on FREETZ_KERNEL_BINUTILS_2_26_DEFAULT || (FREETZ_BUILD_TOOLCHAIN || FREETZ_DL_TOOLCHAIN_OVERRIDE)
+
+       config FREETZ_KERNEL_BINUTILS_2_31
+               bool "binutils-2.31.1"
+               depends on FREETZ_AVM_GCC_8
+               # depends on any kernel version, used by avm for kernel 4.9 only so far
+               depends on FREETZ_KERNEL_BINUTILS_2_31_DEFAULT || (FREETZ_BUILD_TOOLCHAIN || FREETZ_DL_TOOLCHAIN_OVERRIDE)
 endchoice

 choice
@@ -92,6 +129,7 @@
        default FREETZ_KERNEL_GCC_4_7 if FREETZ_AVM_GCC_4_7
        default FREETZ_KERNEL_GCC_4_8 if FREETZ_AVM_GCC_4_8
        default FREETZ_KERNEL_GCC_5   if FREETZ_AVM_GCC_5
+       default FREETZ_KERNEL_GCC_8   if FREETZ_AVM_GCC_8

        config FREETZ_KERNEL_GCC_3_4
                bool "gcc-3.4.6"
@@ -112,6 +150,10 @@
        config FREETZ_KERNEL_GCC_5
                bool "gcc-5.5"
                depends on FREETZ_AVM_GCC_5
+
+       config FREETZ_KERNEL_GCC_8
+               bool "gcc-8.3"
+               depends on FREETZ_AVM_GCC_8
 endchoice

 config FREETZ_KERNEL_BINUTILS_VERSION
@@ -122,6 +164,7 @@
        default "2.24"   if FREETZ_KERNEL_BINUTILS_2_24
        default "2.25.1" if FREETZ_KERNEL_BINUTILS_2_25
        default "2.26.1" if FREETZ_KERNEL_BINUTILS_2_26
+       default "2.31.1" if FREETZ_KERNEL_BINUTILS_2_31

 config FREETZ_KERNEL_GCC_VERSION
        string
@@ -130,8 +173,24 @@
        default "4.7.4" if FREETZ_KERNEL_GCC_4_7
        default "4.8.5" if FREETZ_KERNEL_GCC_4_8
        default "5.5.0" if FREETZ_KERNEL_GCC_5
+       default "8.3.0" if FREETZ_KERNEL_GCC_8
+
+comment "Target toolchain options ----------------------------------------"
+
+config FREETZ_SEPARATE_AVM_UCLIBC_FORCE
+       bool
+       depends on FREETZ_AVM_PROP_UCLIBC_SEPARATE
+       select FREETZ_SEPARATE_AVM_UCLIBC
+       default y
+
+config FREETZ_SEPARATE_AVM_UCLIBC
+       bool "Separate uClibc"
+       depends on FREETZ_SEPARATE_AVM_UCLIBC_FORCE
+       default n
+       help
+               Puts uClibc of Freetz into /usr/lib/freetz/,
+               needs about 1 MB (uncompressed).

-comment "Target toolchain options ----------------------------------"
 choice
        prompt "Target uClibc version"
        default FREETZ_TARGET_UCLIBC_0_9_28 if FREETZ_AVM_UCLIBC_0_9_28
@@ -139,6 +198,7 @@
        default FREETZ_TARGET_UCLIBC_0_9_32 if FREETZ_AVM_UCLIBC_0_9_32
        default FREETZ_TARGET_UCLIBC_0_9_33 if FREETZ_AVM_UCLIBC_0_9_33
        default FREETZ_TARGET_UCLIBC_1_0_14 if FREETZ_AVM_UCLIBC_1_0_14
+       default FREETZ_TARGET_UCLIBC_1_0_15 if FREETZ_AVM_UCLIBC_1_0_15

        config FREETZ_TARGET_UCLIBC_0_9_28
        bool "0.9.28"
@@ -162,6 +222,10 @@
        config FREETZ_TARGET_UCLIBC_1_0_14
        bool "1.0.14"
        depends on FREETZ_AVM_UCLIBC_1_0_14
+
+       config FREETZ_TARGET_UCLIBC_1_0_15
+       bool "1.0.15"
+       depends on FREETZ_AVM_UCLIBC_1_0_15
 endchoice

 comment "CAUTION: Usage of an uClibc version higher than that used by AVM may lead to an unstable box"
@@ -195,12 +259,17 @@
        bool
        depends on FREETZ_KERNEL_BINUTILS_2_25_DEFAULT
        default y
+config FREETZ_TARGET_BINUTILS_2_31_DEFAULT
+       bool
+       depends on FREETZ_KERNEL_BINUTILS_2_31_DEFAULT
+       default y

 choice
        prompt "Target binutils"
        default FREETZ_TARGET_BINUTILS_2_22 if FREETZ_TARGET_BINUTILS_2_22_DEFAULT
        default FREETZ_TARGET_BINUTILS_2_24 if FREETZ_TARGET_BINUTILS_2_24_DEFAULT
        default FREETZ_TARGET_BINUTILS_2_25 if FREETZ_TARGET_BINUTILS_2_25_DEFAULT
+       default FREETZ_TARGET_BINUTILS_2_31 if FREETZ_TARGET_BINUTILS_2_31_DEFAULT

        config FREETZ_TARGET_BINUTILS_2_22
                bool "binutils-2.22"
@@ -216,7 +285,7 @@

        config FREETZ_TARGET_BINUTILS_2_24
                bool "binutils-2.24"
-               # depends on any target GCC version
+               depends on FREETZ_TARGET_GCC_5_MAX
                # depends on any kernel version
                depends on FREETZ_TARGET_BINUTILS_2_24_DEFAULT || (FREETZ_BUILD_TOOLCHAIN || FREETZ_DL_TOOLCHAIN_OVERRIDE)

@@ -231,6 +300,12 @@
                depends on (FREETZ_TARGET_GCC_4_9 || FREETZ_TARGET_GCC_5)
                # depends on any kernel version
                depends on FREETZ_TARGET_BINUTILS_2_26_DEFAULT || (FREETZ_BUILD_TOOLCHAIN || FREETZ_DL_TOOLCHAIN_OVERRIDE)
+
+       config FREETZ_TARGET_BINUTILS_2_31
+               bool "binutils-2.31.1"
+               depends on FREETZ_TARGET_GCC_8
+               # depends on any kernel version
+               depends on FREETZ_TARGET_BINUTILS_2_31_DEFAULT || (FREETZ_BUILD_TOOLCHAIN || FREETZ_DL_TOOLCHAIN_OVERRIDE)
 endchoice

 choice
@@ -240,6 +315,7 @@
        default FREETZ_TARGET_GCC_4_8 if FREETZ_AVM_GCC_4_8
        default FREETZ_TARGET_GCC_4_9 if FREETZ_AVM_GCC_4_9
        default FREETZ_TARGET_GCC_5   if FREETZ_AVM_GCC_5
+       default FREETZ_TARGET_GCC_8   if FREETZ_AVM_GCC_8

        config FREETZ_TARGET_GCC_4_6
                bool "gcc-4.6.4"
@@ -264,6 +340,10 @@
                bool "gcc-5.5"
                depends on FREETZ_AVM_GCC_5 \
                        || (FREETZ_AVM_GCC_5_MAX   && (FREETZ_BUILD_TOOLCHAIN || FREETZ_DL_TOOLCHAIN_OVERRIDE))
+
+       config FREETZ_TARGET_GCC_8
+               bool "gcc-8.3"
+               depends on FREETZ_AVM_GCC_8
 endchoice

 config FREETZ_TARGET_GCC_SNAPSHOT
@@ -325,6 +405,7 @@
 config FREETZ_TARGET_UCLIBC_1
        bool
        default y           if FREETZ_TARGET_UCLIBC_1_0_14
+       default y           if FREETZ_TARGET_UCLIBC_1_0_15
        default n

 config FREETZ_TARGET_UCLIBC_VERSION
@@ -334,6 +415,7 @@
        default "0.9.32.1"  if FREETZ_TARGET_UCLIBC_0_9_32
        default "0.9.33.2"  if FREETZ_TARGET_UCLIBC_0_9_33
        default "1.0.14"    if FREETZ_TARGET_UCLIBC_1_0_14
+       default "1.0.15"    if FREETZ_TARGET_UCLIBC_1_0_15

 config FREETZ_TARGET_UCLIBC_MAJOR_VERSION
        string
@@ -347,6 +429,7 @@
        default "2.24"      if FREETZ_TARGET_BINUTILS_2_24
        default "2.25.1"    if FREETZ_TARGET_BINUTILS_2_25
        default "2.26.1"    if FREETZ_TARGET_BINUTILS_2_26
+       default "2.31.1"    if FREETZ_TARGET_BINUTILS_2_31

 config FREETZ_TARGET_GCC_MAJOR_VERSION
        string
@@ -355,6 +438,7 @@
        default "4.8"       if FREETZ_TARGET_GCC_4_8
        default "4.9"       if FREETZ_TARGET_GCC_4_9
        default "5"         if FREETZ_TARGET_GCC_5
+       default "8"         if FREETZ_TARGET_GCC_8

 config FREETZ_TARGET_GCC_MINOR_VERSION
        depends on !FREETZ_TARGET_GCC_SNAPSHOT
@@ -364,6 +448,7 @@
        default "5"         if FREETZ_TARGET_GCC_4_8
        default "4"         if FREETZ_TARGET_GCC_4_9
        default "5.0"       if FREETZ_TARGET_GCC_5
+       default "3.0"       if FREETZ_TARGET_GCC_8

 config FREETZ_TARGET_GCC_VERSION
        string
@@ -377,6 +462,7 @@
        default "6.0.19"    if FREETZ_TARGET_GCC_4_8
        default "6.0.20"    if FREETZ_TARGET_GCC_4_9
        default "6.0.21"    if FREETZ_TARGET_GCC_5
+       default "6.0.25"    if FREETZ_TARGET_GCC_8

 config FREETZ_STDCXXLIB
        string
@@ -502,7 +588,7 @@
                Build the binutils and gcc to run on the target.
                Files are installed into toolchain/target/target-utils.

-comment "Both kernel and target toolchain related options ----------"
+comment "Both kernel and target toolchain related options ----------------"
 config FREETZ_TOOLCHAIN_MINIMIZE_REQUIRED_GLIBC_VERSION
 #      bool "Minimize required GLIBC version" if FREETZ_BUILD_TOOLCHAIN
        bool
@@ -528,3 +614,4 @@
                in C with more features and better performance.

 endmenu # "Toolchain options" #
+
$
- vielleicht wäre @Massa ja schon geholfen, wenn Du ihm (und anderen, die vor demselben Problem stehen könnten) einfach mal aufschreibst, auf welchem System das mit dem GCC 8.3.0 bei Dir funktioniert hat.

Man ist ja nicht gezwungen, unbedingt Ubuntu zu verwenden (die Versionsangabe 20.01 kommt mir - in Verbindung mit "die aktuellste" - aber auch komisch vor, denn das wäre wohl die 20.04.1) und wenn das auf einem anderen System besser funktioniert, wäre es ja einen Versuch wert.

Wenn ich das richtig sehe, führt ja weder bei Freetz noch bei Freetz-NG mittlerweile ein Weg daran vorbei, daß man sich die eigene Toolchain übersetzen lassen muß (was entsprechende Zeit braucht), wenn man eine halbwegs aktuelle FRITZ!OS-Version benutzen will/muß - da sollte das schon einigermaßen funktionieren, auch dann, wenn man das "from scratch" macht und wenn sich mittlerweile andere "prerequisites" ergeben haben sollten (viele Distributionen bieten 32-Bit-Development-Files nur noch über Kompatibilitätspakete an), wäre sicherlich auch eine "neue Liste" dieser Pakete sinnvoll (falls erforderlich - ich arbeite ohnehin mit einer vollkommen anderen Linux-"Linie", wo die Pakete alle ganz anders heißen und weiß es für Debian/Ubuntu gar nicht immer 100%, was sich da jeweils ändert).

----------------------------------------------------------------------------------------------

Aber hier kommt dann auch gleich noch eine weitere Frage an @Massa dazu ... war das denn auch eine "frische" Konfigurationsdatei oder gab es da ggf. auch entsprechende Leichen drin? Auch ein generelles "make dirclean" fehlt mir oben in #1 irgendwie ... welches "make target" jetzt welche Aufgaben hat, findet man z.B. in einer Datei unterhalb der Freetz-"Installation": https://github.com/Freetz/freetz/blob/master/howtos/make_targets.txt - hat Freetz-NG auch nur wenig geändert. Das (m.W.) neue Ziel "listnewconfig" ist nicht beschrieben und bei Freetz-NG ist halt noch ein uraltes "release"-Target enthalten, was beim Klonen von Freetz-(NG-)Installationen aus VCS-Plattformen im Internet nur noch wenig Sinn ergibt und daher in Freetz auch Geschichte ist.

Die Toolchain-Konfigurationen in Freetz (@fda89 schrieb ja, daß er die - ich denke mal jenseits der Änderungen zum GCC 8 - üblicherweise nicht anpackt) sind auch ein wenig "kritisch" im Hinblick darauf, was sich mit einer "gebrauchten" Konfigurationsdatei dabei ergibt - das hängt in weiten Teilen davon ab, was in der alten Datei stand. Ich hatte mal eine (erbitterte/ausführliche) Diskussion dazu bei Freetz im GitHub (https://github.com/Freetz/freetz/pull/55) - falls sich jemand dafür interessiert, warum man bei neuer Version (der Toolchain, die etwas von den Änderungen zwischen FRITZ!OS-Versionen abhängig ist) am besten mit einer leeren Konfigurationsdatei starten sollte.

Möchte man gerne seine bisherigen Einstellungen zu den ausgewählten Paketen beibehalten (und haben sich bei den Paketen nicht entscheidende Teile geändert, was eher sehr selten der Fall ist), kann man das entweder von Hand übernehmen (alles schön über das "make menuconfig") oder man "bereinigt" diese alte Konfigurationsdatei erst einmal um alle geräte- und versionsspezifischen Anteile (die gerätespezifischen sind spätestens dann im Weg, wenn man mit der Konfiguration auf ein neues Modell umziehen will), bevor man das "make menuconfig" aufruft.

Exakt für diesen Einsatzfall hatte ich den Pull-Request für Freetz ja vorgesehen ... und auch wenn der in Freetz nicht aufgenommen wurde, existiert er weiterhin als Commit in meinem eigenen Fork (der auch nur diese Änderungen beinhaltet) und kann problemlos zu einem Freetz-Checkout hinzugemischt werden (https://github.com/PeterPawn/YourFreetz/commit/38ae6d2749526870fa748fa5d7b0e3242bf87a15). Hat man den bei sich in der Installation, kann man mittels "make reuseconfig" (also "re-use config" - das hat mit Fischfang nichts zu tun) vor einem "make menuconfig" alle Einstellungen entfernen lassen, die bei so einer Konfiguration stören könnten. Dann muß man halt im Menü als ersten Schritt erneut das Modell und die Firmware-Version auswählen - dabei werden dann auch die passenden Einstellungen für die Toolchain erzeugt.

Wie weit der Patch jetzt auch für Freetz-NG paßt (speziell mit der Position im "Makefile" und bei der Frage, ob die Präfix-Liste der zu entfernenden Einstellungen noch stimmt, nachdem die in Freetz-NG ja heftig geändert wurden), weiß ich nicht ... will ich jetzt auch nicht ermitteln. Das kann jeder selbst machen ... alles das, was nach dem "clrconfig" noch mit "...=y" in der ".config" steht, sollte zu Paket-Konfigurationen gehören oder zu anderen Einstellungen, die weder geräte- noch versionsabhängig sind.
 

fda89

Mitglied
Mitglied seit
31 Aug 2020
Beiträge
217
Punkte für Reaktionen
41
Punkte
28
Ich hab nie behauptet dass ich alles weiss noch will ich alles wissen :)
Es gibt keine DL-toolchains mehr seit FOS ~7.0, bei Freetz/ gibts dazu ein Issue noch von mir, es gab da Probleme mit (mindestens) fehlenden scsi Headern.
FREETZ_REAL_DEVELOPER_ONLY__DLTC waren Tests, bei denen die Header fehlten und sind nicht auswählbar

GCC läuft bei mir auf der 7590 und wird überall dort genutzt wo AVM es auch nutzt
Code:
grep GCC_8 config/.img/ -rl
config/.img/6591--07_2X.in
config/.img/6660--07_2X.in
config/.img/6890--07_2X.in
config/.img/7580--DE--07_2X.in
config/.img/7584.in
config/.img/7590--07_2X.in
config/.img/7599.in
Bei deinem Commit fehlt immer noch die Erweiterung von "make help". Die Busybox Settings der 3 verschiedenen versionen könnte man evtl noch hinzufügen
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,255
Punkte für Reaktionen
1,088
Punkte
113
Die Busybox Settings der 3 verschiedenen versionen könnte man evtl noch hinzufügen
Deshalb ist das "clrconfig" so aufgebaut, wie es ist. Man braucht nur die entsprechenden Angaben zeilenweise am Beginn der Datei ergänzen - das ist viel übersichtlicher als ein "for x in ..." und außerdem einfacher (nach Alphabet) zu sortieren. Was jetzt jeder daraus macht, muß er/sie/man selbst entscheiden. Mein Fork basiert auf "Freetz" und das kennt auch nur eine BusyBox-Version zur Auswahl - ergo braucht auch mein Patch (der ja im "Haupt-Branch" von YourFreetz, der auf den Namen "YourFritz" anstelle von "master" hört, auch dazugemischt wird) die entsprechenden Settings nicht. Solltest Du das in Freetz-NG übernehmen (was Dir frei steht), müßte man das halt anpassen. In Freetz wird es ja (siehe die ergebnislose Diskussion im PR) nicht landen.

Die Frage zum GCC 8 war ja, auf welchem System Du das für den Freetz-Build benutzt ... ich erinnere mich da an Diskussionen (mit Dir) im GitHub, wo es u.a. um eine Fedora-Installation ging. Oder willst Du mir mit
GCC läuft bei mir auf der 7590
sagen, daß Du Freetz-NG (und zwar das Build-System und nicht nur ein damit gebautes Image) auf einer 7590 verwendest? Ich wäre äußerst überrascht ...

Davon ausgehend, daß dem nicht so ist, wäre es ja vielleicht hilfreich, die Spezifikationen dieses Build-Systems anzugeben ... angefangen bei der verwendeten Distribution bis hin zu einer Liste der installierten Pakete - notfalls auf das für Freetz Notwendige ausgedünnt. Bei @Massa geht es ja (dem Anschein nach zumindest) erst mal darum, den Cross-Compiler korrekt zu erzeugen - da spielt es noch gar keine Rolle, ob/daß der Cross-Compiler danach für irgendwelche Modelle verwendet werden soll und welche das konkret sind.

Es muß ja irgendeine Ursache haben, wenn bei @Massa (der hoffentlich irgendwann mal wieder Zeit hat, die offenen Fragen zu beantworten) im Verzeichnis "toolchain/build/mips_gcc-8.3.0_uClibc-1.0.15-nptl_kernel-4.9/mips-linux-uclibc/bin/" (trotz des Namens) am Ende ein C++-Compiler gelandet ist, der gar keinen MIPS-Code erzeugt (und deshalb auch die entsprechenden Werte für die Optionen nicht kennt), sondern offensichtlich Code für x86 oder x86_64 (den möglichen Werten für "mtune" nach zu urteilen). Dafür reicht es aber schon, wenn irgendein Makefile für den GCC 8.3.0 anders aufgebaut ist, als beim GCC 5.5.0 und damit ein Patch für die Zielarchitektur ins Leere läuft. Denn eigentlich ist es ja auch eher unwahrscheinlich, daß das verwendete Linux-OS tatsächlich eine (entscheidende) Rolle spielt, denn die Quellen für den GCC 8.3.0 werden ja erst aus dem Netz geladen und da sind dann auch Makefiles etc. enthalten.
 

fda89

Mitglied
Mitglied seit
31 Aug 2020
Beiträge
217
Punkte für Reaktionen
41
Punkte
28
Achso das System... Ja, immer noch das neueste Fedora in einer VM. Das gibts nur als x64, mit enforcing selinux und gcc10 :) Nix besonderes
Das Freetz-Linux von Gismotro ist ein Ubuntu 20.04 x64 damit gehts wohl auch. Da muss Masse wohl mehr Info liefern
Welche Pakete man für Freetz braucht .. keine Ahnung. Niemand (inklusive mir) hatte seit Jahren Lust das im Wiki zu aktualisieren. make sagt aber wenn was fehlt oder bricht ab
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,255
Punkte für Reaktionen
1,088
Punkte
113
Ich habe jetzt mal (nur aus Quatsch) einen Build mit Freetz-NG bei mir auf einem MacMini (noch mit Core2 Duo, also schon älter) mit Linux (openSUSE Tumbleweed) durchlaufen lassen - 7590 mit 07.20, nichts weiter als "Experte" und die Box ausgewählt, sowie (sinnvollere) Einstellungen zur Optimierung (weil meinetwegen die Binaries auch 5x so groß werden dürfen, wenn sie dann wenigstens doppelt so schnell laufen):
Code:
[email protected]:/tmp/freetz-ng> cat .config.compressed
FREETZ_USER_LEVEL_EXPERT=y
FREETZ_TARGET_CFLAGS="-Ofast -pipe"
FREETZ_FWMOD_SKIP_PACK=y
[email protected]:/tmp/freetz-ng>
Nach ca. 1 Stunde war der Build erledigt - und er funktionierte auch (bis zu dem Punkt, wo er sollte). Hätte es jetzt noch eine Option gegeben, sich eine Datei für den Start aus dem RAM ausgeben zu lassen (das Packen habe ich ja übersprungen - das ist nun mal "Routine" bei mir, die ich bei Freetz bzw. bei meinem Fork auch abspule), könnte ich diese sogar auf die 7590 laden. :cool:

Die Protokolldatei hänge ich hier mal nicht komplett ran (da spielt der Server ohnehin nicht mit) - auch wenn damit andere (spätere) Leser verstehen würden, warum die paar Zeilen aus #1 nur eine ungefähre Vorstellung vermitteln können, wo es am Ende tatsächlich klemmt. (M)Eine vollständige Protokoll-Datei (der Build enthielt auch nur das Nötigste, siehe .config oben) ist eben mal 13 MB groß und umfaßt 45361 Zeilen. Selbst wenn man nur die letzten 1000 Zeilen "zeigt", kriegt jemand, der sich damit einigermaßen auskennt, doch eine viel treffendere Vorstellung davon, WO der Build gerade ist, als bei den paar Zeilen aus #1.

Und es tut auch gar nicht weh, diese Protokoll-Datei (selbst) zu erstellen ... anstelle des "make" benutzt man einfach ein "./fmake" - welche Optionen das dann versteht, verrät es auch selbst, wenn man es mit "./fmake -h" aufruft (im Freetz-(NG-)Verzeichnis natürlich, wie bei jedem "make", denn das sucht immer im lokalen Verzeichnis nach dem "Makefile", wenn man ihm keines beim Aufruf mitgibt).

Alles das, was da "more sophisticated" ist bei den "fmake"-Optionen, wie Pre- und Post-Processing, braucht man gar nicht ... es reicht schon ein "./fmake -c -t", damit man (a) die Ausgaben auf der Console sieht und sie (b) in einer Datei mit einem Namen, der noch das Datum enthält, gespeichert werden, so daß man also auch über mehrere Anläufe "Protokoll führen" kann.
 
Zuletzt bearbeitet:
  • Like
Reaktionen: gismotro

gismotro

Mitglied
Mitglied seit
5 Sep 2007
Beiträge
407
Punkte für Reaktionen
59
Punkte
28
Hier ein kleines HowTo zum selberbauen einer eigenen Freetz-Linux-VM :

1.) aktuelle VirtualBox v.6.1.14 vom Server laden :
Download von Oracle VM VirtualBox

2.) Download eines aktuellen Ubuntu Releases

3.) Pakete nachladen :
Code:
sudo apt update && sudo apt upgrade
4. SSH Zugriff aktivieren:
Code:
sudo apt-get install ssh
5.) VSFTP installieren:
Quelle : hxxps://linuxconfig.org/how-to-setup-ftp-server-on-ubuntu-18-04-bionic-beaver-with-vsftpd

a.)Vsftpd addon instalieren
Code:
 sudo apt-get -y install vsftpd
b.) vsftpd.conf Datei bearbeiten
Code:
sudo nano /etc/vsftpd.conf
Alles in der Datei löschen und folgenden Inhalt einfügen:
Code:
listen=NO
listen_ipv6=YES
anonymous_enable=NO
local_enable=YES
write_enable=YES
local_umask=022
dirmessage_enable=YES
use_localtime=YES
xferlog_enable=YES
connect_from_port_20=YES
chroot_local_user=YES
secure_chroot_dir=/var/run/vsftpd/empty
pam_service_name=vsftpd
rsa_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
rsa_private_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
ssl_enable=NO
pasv_enable=Yes
pasv_min_port=10000
pasv_max_port=10100
allow_writeable_chroot=YES
c.) Port öffnen:
Code:
sudo ufw allow from any to any port 20,21,10000:10100 proto tcp
d.) Vsftpd neu starten /rebooten:
Code:
sudo service vsftpd restart
6.) fehlende Freetz-Pakete nachladen:
Code:
sudo apt-get -y install imagemagick subversion git gcc g++ binutils autoconf automake autopoint libtool-bin net-tools make bzip2 libncurses5-dev libreadline-dev librsvg2-dev librsvg2-bin libxml2-dev imagemagick imagemagick-doc zlib1g-dev flex bison patch texinfo tofrodos gettext pkg-config ecj fastjar perl ncftp libstring-crc32-perl ruby ruby1.8 gawk python libusb-dev unzip intltool libacl1-dev libcap-dev libc6-dev-i386 lib32ncurses5-dev gcc-multilib lib32stdc++6 libglib2.0-dev build-essential inkscape unar
7.) umask 0022:re

a.) Folgende Datei bearbeiten:
Code:
sudo nano /etc/pam.d/common-session
b.) Find the line with "session optional pam_umask.so"
c.) Change this to "session optional pam_umask.so umask=0022"
d.) Reboot.

8.) Runlevel ändern:

a.) Grub bearbeiten
Code:
sudo nano /etc/default/grub
b.) GRUB_CMDLINE_LINUX="3" (im Text ändern)
c.) Grub neu starten
Code:
sudo update-grub
9.) Hinweis aus IPPF beachten: "Nur dieses "Cloud-init" benötige ich nicht. Deswegen gleich wieder deinstalliert" :
Code:
sudo apt-get remove cloud-init
10.) Samba installieren:

a.) Samba installieren:
Code:
sudo apt install samba -y
b.) smb.conf Datei anpassen:
Code:
sudo nano /etc/samba/smb.conf
Diese Zeilen Editieren :
Code:
workgroup = Freetz-NET
Diesen Part hinzufügen :
Code:
[freetz]
   comment = Freetz homedir
   browseable = yes
   force user = freetz
   directory mask = 0755
   create mask = 0644
   read only = false
   path = /home/freetz
c.) Samba-Nutzer Pw setzen:
Code:
sudo smbpasswd -a freetz
11.)Anzeige von Menuconfig anpassen bei Darstellungsfehlern im Putty:
per nano folgende Zeile in die .profile einfügen (nur bei Bedarf)
Code:
TERM=putty-256color
Hinweis: Man sollte sich besser mit Putty zur VM verbinden. Das Fenster ist dann grösser und man kann einfach Text kopieren/einfügen.

12.) Spracheinstellung von Ubuntu auf Deutsch umstellen (optional, aber nicht zwingend Notwendig):

a.) Sprachpakete installieren:
Code:
sudo apt install locales
Wir können uns die aktuellen Einstellung ansehen:
Code:
locale -a
Sollte die Sprache „Deutsch“ mit UTF-8 nicht nicht erzeugt sein, so sollten wir es jetzt vornehmen.
Code:
sudo locale-gen de_DE.UTF-8
b.) Die Einstellungen für die Sprache können wir mit einem grafischen Tool einfach ändern.
Code:
sudo dpkg-reconfigure locales
Nach der Umstellung sollten nur Einträg welche ausgewählt wurden in der Datei enthalten sein.
Code:
cat /etc/locale.gen
Code:
de_DE.UTF-8 UTF-8
c.) Für unsere Umgebung müssen wir ggf. noch die Einstellungen hinterlegen : sudo nano /etc/default/locale
Code:
LANG=de_DE.UTF-8
LANGUAGE=de_DE.UTF-8
LC_MESSAGES=de_DE.UTF-8
d.) sudo nano /etc/environment
Code:
LC_ALL=de_DE.UTF-8
LANG=de_DE.UTF-8
e.) Deutsche Sprache aktivieren:
Code:
sudo apt-get update
Code:
sudo apt-get install language-pack-de language-pack-de-base
13.) Final Updates laden und System säubern:
Code:
sudo apt dist-upgrade && sudo apt autoclean && sudo apt autoremove
 
Zuletzt bearbeitet:
  • Like
Reaktionen: fda89 und prisrak1

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,255
Punkte für Reaktionen
1,088
Punkte
113
@gismotro:
Vielleicht solltest Du noch irgendwie hervorheben, daß die Installation von Samba und "vsftpd" für Freetz eigentlich nicht erforderlich ist, damit das niemand falsch versteht.

Das mag zwar für manchen Benutzer dann eine Erleichterung sein, wenn es darum geht, wie er die (Image-)Dateien aus der VM heraus bekommt, aber wer ohnehin mit PuTTY (oder auch KiTTY) per SSH auf die VM zugreift und nicht in der Console dieser VM arbeitet (die ist üblicherweise viel unhandlicher, angefangen beim fehlenden Scrollback-Buffer), der kann die Dateien natürlich auch einfach per SCP oder SFTP kopieren und braucht weder FTP- noch Samba-Server ... wenn er die Dateien überhaupt aus der VM bekommen will und sie nicht gleich von dort auf die FRITZ!Box bringt.

Ein Freetz-Build funktioniert auch ohne diese - da die beiden in der Liste mittendrin "eingewoben" wurden, kann man aber nicht einfach sagen, daß die Liste nur bis zum Punkt X auch notwendig wäre.
 
  • Like
Reaktionen: gismotro

Massa

Mitglied
Mitglied seit
18 Dez 2004
Beiträge
200
Punkte für Reaktionen
4
Punkte
18
Uff - kaum hat man nicht sofort Zeit, kommt man ja gar nicht mehr hinterher zu antworten :eek:
Erst einmal vielen Dank für Eure zahlreichen Hilfestellungen!

Ich versuche jetzt mal, diese zu beantworten bzw. weitere Informationen zu geben (ich dachte, da ich den gleichen Fehler für mehrere Konfigurationen bekomme, dass das Problem kein Konfigurationsproblem wäre - da habe ich mich wohl getäuscht).

Zuerst einmal: ich übersetze freetz bzw. freetz-ng schon seit Jahren - habe jetzt nur vor einigen Monaten eine neue Buildumgebung mit 64-Bit Ubuntu aufgesetzt, weil meine bis dato verwendete 32-Bit Umgebung nicht mehr updatefähig war.
Das Ubuntu halte ich über apt-get update && apt-get dist-upgrade etc. immer auf dem aktuellen Stand - bei einem Upgrade warte ich meistens etwas (bis die .1 Version rauskommt).
Aktuell bin ich auf 20.04.1 mit aktuellen Paketen (das wollte ich eigentlich mit "aktuellem Stand" sagen) - die Meldung oben mit 20.01 war falsch! :oops:


@PeterPawn: Deine Vermutung, dass der o.a. Fehler durch ein angewähltes "Build Toolchain für Target" herkommt war korrekt - wobei ich mir nicht erklären kann, wieso das in all meinen Konfigurationen - sowohl bei den 7590 als auch den 7490-Konfigurationen aktiviert ist (die unterschiedlichen Konfigurationen _einer_ Box erstelle ich tatsächlich durch kopieren der .config und dann ein "make oldconfig" gefolgt von "make menuconfig" und wechseln der Firmware Version.

Achja: fmake kannte ich bis dato tatsächlich noch nicht - man lernt niemals aus ;)

Wie dem auch sei: ich habe die Option mal weg genommen (brauche ich eigentlich auch nicht) und nochmal gebaut.
Für meine 7490 mit FW7.1-Konfiguration kam dann am Ende:
Code:
WARNING: File of kernel module not found: arc4.ko
WARNING: File of kernel module not found: bfusb.ko
WARNING: File of kernel module not found: bluetooth.ko
WARNING: File of kernel module not found: bnep.ko
WARNING: File of kernel module not found: btusb.ko
WARNING: File of kernel module not found: cifs.ko
WARNING: File of kernel module not found: cmac.ko
WARNING: File of kernel module not found: des_generic.ko
WARNING: File of kernel module not found: ecb.ko
WARNING: File of kernel module not found: hmac.ko
WARNING: File of kernel module not found: iso9660.ko
WARNING: File of kernel module not found: l2cap.ko
WARNING: File of kernel module not found: md4.ko
WARNING: File of kernel module not found: md5.ko
WARNING: File of kernel module not found: rfcomm.ko
WARNING: File of kernel module not found: usbmon.ko
ERROR: Enable missing with 'make kernel-menuconfig' as (M)odule (and push a pull request). Use '/' to search in menuconfig.
make: *** [Makefile:275: firmware-nocompile] Error 1
Was ich dann versucht habe, mühsam über "make kernel-menuconfig" und Suche / Anwahl verschiedener Module zu lösen.
Im bisherigen Endergebnis (config_7490-7.1.txt) werden immer noch iso9660.ko und l2cap.ko angemeckert - obowohl ich eigentlich mein, die iso9660 gefunden und angewählt zu haben (l2cap aber leider nicht) (Logging siehe fmake_7490-7.1x.txt)
Wieso muss ich das eigentlich machen? Warum werden die nicht automatisch korrekt aufgelöst und ausgewählt?

Für meine 7590 mit FW7.2-Konfiguration kommt jetzt ein Fehler beim bauen der SquashFS-Tools:
Code:
make[1]: Entering directory '/home/freetz/workdir/git.7590-ng_7.20/source/target-mips_gcc-8.3.0_uClibc-1.0.15-nptl_kernel-4.9/squashfs4-be-4.3/squashfs-tools'
/home/freetz/workdir/git.7590-ng_7.20/toolchain/build/mips_gcc-8.3.0_uClibc-1.0.15-nptl_kernel-4.9/mips-linux-uclibc/bin/mips-linux-uclibc-gcc  -Wl,--gc-sections  mksquashfs.o read_fs.o action.o swap.o pseudo.o compressor.o sort.o progressbar.o read_file.o info.o           process_fragments.o caches-queues-lists.o gzip_wrapper.o lzma_xz_wrapper.o xz_wrapper.o -lpthread -lm  -lz   -llzma   -llzma  -o mksquashfs
make[1]: 'unsquashfs' is up to date.
/home/freetz/workdir/git.7590-ng_7.20/toolchain/build/mips_gcc-8.3.0_uClibc-1.0.15-nptl_kernel-4.9/mips-linux-uclibc/lib/gcc/mips-linux-uclibc/8.3.0/../../../../mips-linux-uclibc/bin/ld: mksquashfs.o: in function `scan1_readdir':
mksquashfs.c:(.text.scan1_readdir+0x44): undefined reference to `create_dir_entry'
/home/freetz/workdir/git.7590-ng_7.20/toolchain/build/mips_gcc-8.3.0_uClibc-1.0.15-nptl_kernel-4.9/mips-linux-uclibc/lib/gcc/mips-linux-uclibc/8.3.0/../../../../mips-linux-uclibc/bin/ld: mksquashfs.o: in function `create_inode':
mksquashfs.c:(.text.create_inode+0x510): undefined reference to `get_parent_no'
/home/freetz/workdir/git.7590-ng_7.20/toolchain/build/mips_gcc-8.3.0_uClibc-1.0.15-nptl_kernel-4.9/mips-linux-uclibc/lib/gcc/mips-linux-uclibc/8.3.0/../../../../mips-linux-uclibc/bin/ld: mksquashfs.c:(.text.create_inode+0x67c): undefined reference to `get_parent_no'
/home/freetz/workdir/git.7590-ng_7.20/toolchain/build/mips_gcc-8.3.0_uClibc-1.0.15-nptl_kernel-4.9/mips-linux-uclibc/lib/gcc/mips-linux-uclibc/8.3.0/../../../../mips-linux-uclibc/bin/ld: mksquashfs.o: in function `reader_read_process':
mksquashfs.c:(.text.reader_read_process+0x1d0): undefined reference to `is_fragment'
/home/freetz/workdir/git.7590-ng_7.20/toolchain/build/mips_gcc-8.3.0_uClibc-1.0.15-nptl_kernel-4.9/mips-linux-uclibc/lib/gcc/mips-linux-uclibc/8.3.0/../../../../mips-linux-uclibc/bin/ld: mksquashfs.o: in function `reader_read_file':
mksquashfs.c:(.text.reader_read_file+0x210): undefined reference to `is_fragment'
/home/freetz/workdir/git.7590-ng_7.20/toolchain/build/mips_gcc-8.3.0_uClibc-1.0.15-nptl_kernel-4.9/mips-linux-uclibc/lib/gcc/mips-linux-uclibc/8.3.0/../../../../mips-linux-uclibc/bin/ld: mksquashfs.o: in function `scan1_encomp_readdir':
mksquashfs.c:(.text.scan1_encomp_readdir+0xd8): undefined reference to `add_dir_entry2'
/home/freetz/workdir/git.7590-ng_7.20/toolchain/build/mips_gcc-8.3.0_uClibc-1.0.15-nptl_kernel-4.9/mips-linux-uclibc/lib/gcc/mips-linux-uclibc/8.3.0/../../../../mips-linux-uclibc/bin/ld: mksquashfs.c:(.text.scan1_encomp_readdir+0x284): undefined reference to `create_dir_entry'
/home/freetz/workdir/git.7590-ng_7.20/toolchain/build/mips_gcc-8.3.0_uClibc-1.0.15-nptl_kernel-4.9/mips-linux-uclibc/lib/gcc/mips-linux-uclibc/8.3.0/../../../../mips-linux-uclibc/bin/ld: mksquashfs.o: in function `dir_scan2':
mksquashfs.c:(.text.dir_scan2+0x2d8): undefined reference to `create_dir_entry'
/home/freetz/workdir/git.7590-ng_7.20/toolchain/build/mips_gcc-8.3.0_uClibc-1.0.15-nptl_kernel-4.9/mips-linux-uclibc/lib/gcc/mips-linux-uclibc/8.3.0/../../../../mips-linux-uclibc/bin/ld: mksquashfs.c:(.text.dir_scan2+0x398): undefined reference to `add_dir_entry'
/home/freetz/workdir/git.7590-ng_7.20/toolchain/build/mips_gcc-8.3.0_uClibc-1.0.15-nptl_kernel-4.9/mips-linux-uclibc/lib/gcc/mips-linux-uclibc/8.3.0/../../../../mips-linux-uclibc/bin/ld: mksquashfs.c:(.text.dir_scan2+0x3d8): undefined reference to `add_dir_entry2'
/home/freetz/workdir/git.7590-ng_7.20/toolchain/build/mips_gcc-8.3.0_uClibc-1.0.15-nptl_kernel-4.9/mips-linux-uclibc/lib/gcc/mips-linux-uclibc/8.3.0/../../../../mips-linux-uclibc/bin/ld: mksquashfs.o: in function `dir_scan4':
mksquashfs.c:(.text.dir_scan4+0xa8): undefined reference to `free_dir_entry'
/home/freetz/workdir/git.7590-ng_7.20/toolchain/build/mips_gcc-8.3.0_uClibc-1.0.15-nptl_kernel-4.9/mips-linux-uclibc/lib/gcc/mips-linux-uclibc/8.3.0/../../../../mips-linux-uclibc/bin/ld: mksquashfs.o: in function `dir_scan1':
mksquashfs.c:(.text.dir_scan1+0x148): undefined reference to `free_dir_entry'
/home/freetz/workdir/git.7590-ng_7.20/toolchain/build/mips_gcc-8.3.0_uClibc-1.0.15-nptl_kernel-4.9/mips-linux-uclibc/lib/gcc/mips-linux-uclibc/8.3.0/../../../../mips-linux-uclibc/bin/ld: mksquashfs.c:(.text.dir_scan1+0x2fc): undefined reference to `free_dir_entry'
/home/freetz/workdir/git.7590-ng_7.20/toolchain/build/mips_gcc-8.3.0_uClibc-1.0.15-nptl_kernel-4.9/mips-linux-uclibc/lib/gcc/mips-linux-uclibc/8.3.0/../../../../mips-linux-uclibc/bin/ld: mksquashfs.c:(.text.dir_scan1+0x320): undefined reference to `lookup_inode'
/home/freetz/workdir/git.7590-ng_7.20/toolchain/build/mips_gcc-8.3.0_uClibc-1.0.15-nptl_kernel-4.9/mips-linux-uclibc/lib/gcc/mips-linux-uclibc/8.3.0/../../../../mips-linux-uclibc/bin/ld: mksquashfs.c:(.text.dir_scan1+0x330): undefined reference to `add_dir_entry'
/home/freetz/workdir/git.7590-ng_7.20/toolchain/build/mips_gcc-8.3.0_uClibc-1.0.15-nptl_kernel-4.9/mips-linux-uclibc/lib/gcc/mips-linux-uclibc/8.3.0/../../../../mips-linux-uclibc/bin/ld: mksquashfs.o: in function `dir_scan':
mksquashfs.c:(.text.dir_scan+0xd4): undefined reference to `create_dir_entry'
/home/freetz/workdir/git.7590-ng_7.20/toolchain/build/mips_gcc-8.3.0_uClibc-1.0.15-nptl_kernel-4.9/mips-linux-uclibc/lib/gcc/mips-linux-uclibc/8.3.0/../../../../mips-linux-uclibc/bin/ld: mksquashfs.c:(.text.dir_scan+0x288): undefined reference to `lookup_inode'
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:244: mksquashfs] Error 1
make[1]: Leaving directory '/home/freetz/workdir/git.7590-ng_7.20/source/target-mips_gcc-8.3.0_uClibc-1.0.15-nptl_kernel-4.9/squashfs4-be-4.3/squashfs-tools'

ERROR: Build failed.
make: *** [make/squashfs4-be/squashfs4-be.mk:31: source/target-mips_gcc-8.3.0_uClibc-1.0.15-nptl_kernel-4.9/squashfs4-be-4.3/squashfs-tools/mksquashfs] Error 1
make
    exit code 0
    duration 0m14.190s
Konfiguration: config_7590-7.2.txt Logging: fmake_7590-7.2.x.log
(übrigens: ursprünglich hatte ich in der Konfiguration auch noch eSpeak mit allen Sprachen drin - das hatte aber auch nicht gebaut, deswegen habe ich es mal abgwählt)

Die anderen beiden Konfigurationen (7490 für FW7.2 und 7590 für FW7.1) müssen noch gebaut werden...
 

Anhänge

Zuletzt bearbeitet:

fda89

Mitglied
Mitglied seit
31 Aug 2020
Beiträge
217
Punkte für Reaktionen
41
Punkte
28
@PeterPawn
> sich eine Datei für den Start aus dem RAM ausgeben
nach "make" einfach "tools/image2inmemory" ohne irgendwas aufrufen. Dies erstellt aus dem letzten .image eine .inmemory. Man kann als Parameter aber auch jedes andere (nicht-ng) image angeben

> FREETZ_TARGET_CFLAGS="-Ofast -pipe"
Gib es irgendwas zu beachten wenn man das benutzt? Abgesehen von der Dateigrösse.

@gismotro
Du könntest noch dazuschreiben dass man sich mit Putty zur VM verbinden soll. Das Fenster ist dann grösser und man kann einfach Text kopieren/einfügen

> 6.) fehlende Freetz-Pakete nachladen:
Ist das die vollständige Liste fürs aktuelle Ubuntu?
Auf https://freetz-ng.github.io/freetz-ng/wiki/10_Beginner/install.de.html#installation-der-benötigten-pakete-ubuntu gibt es unten rechts "Improve this page"

@Massa
> Wieso muss ich das eigentlich machen? Warum werden die nicht automatisch korrekt aufgelöst und ausgewählt?
Stmmt, ist ne Sauerei! Aber auch die Gelegenheit für dich!! Du könntst der erste sein!!!
Wenn du schon dabei bist, für die etwa 15 anderen Kernel bitte auch. Natürlich testen ob es noch compiliert. Das bauen jeder Toolchain kann bisschen dauern (1-2 Stunden je)
Mit 7490 7.2x sollte autofs+cifs ohne Änderungen funktionieren

> ein angewähltes "Build Toolchain für Target"
Vielleicht sollte man das dann nicht für arm/x86 anbieten?
Die 7490 und 7590 haben übrigens kein ARM.

> die unterschiedlichen Konfigurationen _einer_ Box erstelle ich tatsächlich durch kopieren der .config und dann ein "make oldconfig" gefolgt von "make menuconfig" ...
Ob das klappt ist so ne Sache. Garantiert ist es nicht!
 

Massa

Mitglied
Mitglied seit
18 Dez 2004
Beiträge
200
Punkte für Reaktionen
4
Punkte
18
@Massa
> Wieso muss ich das eigentlich machen? Warum werden die nicht automatisch korrekt aufgelöst und ausgewählt?
Stmmt, ist ne Sauerei! Aber auch die Gelegenheit für dich!! Du könntst der erste sein!!!
Wenn du schon dabei bist, für die etwa 15 anderen Kernel bitte auch. Natürlich testen ob es noch compiliert. Das bauen jeder Toolchain kann bisschen dauern (1-2 Stunden je)
Mit 7490 7.2x sollte autofs+cifs ohne Änderungen funktionieren
Ich meinte damit nicht, dass ich mich beschwere und dass es eine "Sauerei" ist - ich meinte damit nur, dass das für mich neu ist und das bei mir erst seit ca. 2 Monaten auftritt - davor war es tatsächlich so, dass es automatisch korrekt aufgelöst wurde
(bis zu dem Zeitpunkt, an dem die Meldung kam hatte ich "make kernel-menuconfig" noch nie aufgerufen...)
Aber interessehalber: wie wäre denn da der Mechanismus, damit das automatisch ausgewählt wird?
Und wo werden eigentlich die Konfig-Daten beim "make kernel-menuconfig" gespeichert? Auch in der .config? Oder in einer anderen Datei?

@Massa
> die unterschiedlichen Konfigurationen _einer_ Box erstelle ich tatsächlich durch kopieren der .config und dann ein "make oldconfig" gefolgt von "make menuconfig" ...
Ob das klappt ist so ne Sache. Garantiert ist es nicht!
Oh - ich dachte, das Kopieren eine .config in einen jungfräulichen git-Clon gefolgt von "make oldconfig" wäre relativ "sicher"? :oops:
 

fda89

Mitglied
Mitglied seit
31 Aug 2020
Beiträge
217
Punkte für Reaktionen
41
Punkte
28
  • Like
Reaktionen: gismotro

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,255
Punkte für Reaktionen
1,088
Punkte
113
Gib es irgendwas zu beachten wenn man das benutzt?
Mir wäre nichts bekannt - ich übersetze die Binaries, die ich zum Download bereitstelle (yf_bin) und in "modfs" auch verwende, schon seit langem nur noch mit "-ofast". Irgendwo gibt es bestimmt auch noch die passende Diskussion dazu im Freetz-Repo auf GitHub - die von Freetz(-NG) verwendeten Optimierungen machen halt nur so lange Sinn, wie man tatsächlich die kleinsten Dateien der Welt erzeugen will. Bei AVM findet man auch Hinweise darauf, daß dort wohl überwiegend "-O2" (was m.W. Standard ist, aber gerne auch mal explizit angegeben wird, weil andere Optionen die Optimierungen auch beeinflussen können) verwendet wird.

nach "make" einfach "tools/image2inmemory" ohne irgendwas aufrufen.
Sooo einfach ist es dann auch wieder nicht - und es bleibt dabei, daß das nur "Quatsch" oder "Spaß" meinerseits war, als ich ein Freetz-NG-Image gebaut habe. Ich nutze überhaupt keinen "Freetz-Mod" (weder mit Freetz noch mit Freetz-NG) und dabei wird es auch bleiben.

Man hat ja in Freetz (wo es wenigstens noch das direkte Erzeugen der Datei gibt - aber das hatten wir ja gerade erst) auch nur die Möglichkeit, das "Pack image" komplett zu übergehen und dann wird nicht mal ein SquashFS-Image für das Dateisystem erzeugt, womit auch
Dies erstellt aus dem letzten .image eine .inmemory.
ins Leere laufen würde.

Solange man das in Freetz(-NG) (beim "Image-Builder", wenn man mal wieder meine Theorie zu den "vier Teilen" von Freetz zugrunde legt) nur komplett aus- oder abwählen kann (bei ausgewählter Option wird dann aber auch stramm noch ein TAR-File als Image erzeugt, selbst wenn man das nicht braucht und nicht haben will), gibt das für jemanden, der nur ein Image zum Start der FRITZ!Box aus dem Speicher haben will, in jedem Falle zusätzliche Arbeitsschritte in "fwmod" und damit auch zusätzliche, potentielle Fehlerquellen.

Vielleicht sollte man das dann nicht für arm/x86 anbieten?
Ich verstehe immer noch nicht, wo Du da in #1 irgendetwas von "ARM" liest. Kannst Du mir das deutlicher machen? Selbst wenn ich im HTML-Text suche, finde ich die erste Erwähnung von ARM in einem Beitrag von Dir.

Aber ich kann den Fehler von @Massa beim Build der Tools für die Box nachvollziehen:
Rich (BBCode):
make[3]: Entering directory '/tmp/freetz-ng/source/toolchain-mips_gcc-8.3.0_uClibc-1.0.15-nptl_kernel-4.9/gcc-8.3.0-target/build-x86_64-pc-linux-gnu/libcpp'
g++  
   -I/tmp/freetz-ng/source/toolchain-mips_gcc-8.3.0_uClibc-1.0.15-nptl_kernel-4.9/gcc-8.3.0/libcpp 
   -I. 
   -I/tmp/freetz-ng/source/toolchain-mips_gcc-8.3.0_uClibc-1.0.15-nptl_kernel-4.9/gcc-8.3.0/libcpp/../include 
   -I/tmp/freetz-ng/source/toolchain-mips_gcc-8.3.0_uClibc-1.0.15-nptl_kernel-4.9/gcc-8.3.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/tmp/freetz-ng/source/toolchain-mips_gcc-8.3.0_uClibc-1.0.15-nptl_kernel-4.9/gcc-8.3.0/libcpp 
   -I. 
   -I/tmp/freetz-ng/source/toolchain-mips_gcc-8.3.0_uClibc-1.0.15-nptl_kernel-4.9/gcc-8.3.0/libcpp/../include 
   -I/tmp/freetz-ng/source/toolchain-mips_gcc-8.3.0_uClibc-1.0.15-nptl_kernel-4.9/gcc-8.3.0/libcpp/include
   -c 
   -o charset.o 
   -MT charset.o 
   -MMD 
   -MP 
   -MF .deps/charset.Tpo 
      /tmp/freetz-ng/source/toolchain-mips_gcc-8.3.0_uClibc-1.0.15-nptl_kernel-4.9/gcc-8.3.0/libcpp/charset.c
/usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/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 icelake-server cascadelake bonnell atom silvermont slm goldmont goldmont-plus tremont knl knm x86-64 eden-x2 nano nano-1000 nano-2000 nano-3000 nano-x2
eden-x4 nano-x4 k8 k8-sse3 opteron opteron-sse3 athlon64 athlon64-sse3 athlon-fx amdfam10 barcelona bdver1 bdver2 bdver3 bdver4 znver1 znver2 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 icelake-server cascadelake bonnell atom silvermont slm goldmont goldmont-plus tremont knl knm intel x86-64 eden-x2 nano nano-1000 nano-2000 nano-3000 nano-x2
eden-x4 nano-x4 k8 k8-sse3 opteron opteron-sse3 athlon64 athlon64-sse3 athlon-fx amdfam10 barcelona bdver1 bdver2 bdver3 bdver4 znver1 znver2 btver1 btver2 generic native
make[3]: *** [Makefile:224: charset.o] Error 1
make[3]: Leaving directory '/tmp/freetz-ng/source/toolchain-mips_gcc-8.3.0_uClibc-1.0.15-nptl_kernel-4.9/gcc-8.3.0-target/build-x86_64-pc-linux-gnu/libcpp'
make[2]: *** [Makefile:2743: all-build-libcpp] Error 2
(mit Umbruch, sonst kann das in einer Code-Box niemand lesen, dafür mit Farbe zur Unterscheidung)
Hier wird in Zeile 2 der "g++" des Build-Hosts aufgerufen zum Übersetzen der "libcpp" (der dann natürlich auch seinen (x86_64-)Assembler verwendet und "-trap" ist eine MIPS-Option) und nicht der Cross-Compiler, der die verwendeten Optionen (auch "march" und "mtune") dann wieder verstehen würde.

Da fehlt irgendwo ein Patch, der dafür sorgt, daß an dieser Stelle ein (hoffentlich angegebener) Pfad für den Cross-Compiler auch berücksichtigt wird - wo das genau ist, muß man sich halt mal in Ruhe ansehen. Wenn ich mir die Unterschiede bei den Patches für GCC 8 und GCC 5 ansehe (https://github.com/Freetz-NG/freetz-ng/tree/master/toolchain/make/target/gcc/5 vs. https://github.com/Freetz-NG/freetz-ng/tree/master/toolchain/make/target/gcc/8) würde ich aber ohnehin mal die These in den Raum stellen, daß da für Freetz-NG und GCC 8 ein paar Patches einfach in den Skat gedrückt wurden an dieser Stelle. Es ist sicherlich etwas speziell, mit einem Cross-Compiler auch noch den Compiler zu erzeugen, der auf der Zielplattform laufen kann - da kann es schon mal passieren, daß in einer Quelldatei aus den GCC 8.3-Sources bei dieser Aufgabenstellung eine (üblicherweise leere) Variable fehlt im Pfadnamen irgendwelcher Tools.
 
Zuletzt bearbeitet:

Massa

Mitglied
Mitglied seit
18 Dez 2004
Beiträge
200
Punkte für Reaktionen
4
Punkte
18
Andere Datei. Siehe Ausgabe von "git status" / "git diff"
Huh?
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?
Und wie würde ich die dann ggf. wieder zurückspielen?

Es gab darüber schon öfter Beschwerden, ist mir aber zuviel Aufwand
Ich finde es extrem schwer, da die richtigen Kernel-Module zu finden und anzuwählen - zumal es doch über make menuconfig auch schon die Möglichkeit gibt, Kernel-Module auszuwählen.
So richtig verstehe ich den Zusammenhang ehrlich gesagt nicht...

Bevor es diese Meldung gab, wurde Module einfach nicht ins Image gepackt, wenn sie nicht da waren
Eine Meldung ist schon gut - muss das denn (sinnvollerweise) zum Abbruch führen?

Es können falsche Dinge in der .config sein, PeterPawn hatte oben dies verlinkt (nicht in Freetz): https://github.com/PeterPawn/YourFreetz/commit/38ae6d2749526870fa748fa5d7b0e3242bf87a15
Damit könnte man das "aufräumen"?

Übrigens habe ich es nach längerem hin- und herspielen mit den Kernelmodulen jetzt geschafft, eine Version für 7490 mit FW7.2x zu bauen - ob die auch läuft, kann ich allerdings erst in ein paar Tagen testen... ;)
 

Anhänge

fda89

Mitglied
Mitglied seit
31 Aug 2020
Beiträge
217
Punkte für Reaktionen
41
Punkte
28
Beim Bau des Kernels wird diese und sein Module gebaut. Ins Image kommen diese Datein nur wenn sie in Freetz ausgewählt sind.
Zwischen diesen Dingen gibt es keine direkte Verbindung, jede Box nutzt den kernel+config die passt (von avm verwendet wird)
Die kernel-config basiert auf der von avm, da sind nicht die module drin die man möglicherweise haben möchte.
Zuviele module bauen ist somit kein Problem da diese nicht ins Image kommen.
Deshlab 1x die make/linux/configs/freetz/config-* so bearbeiten wie du sie brauchst und einen PR machen (steht ja in der Meldung!)
Dann brauchst du und auch sonst niemand das nochmal zu machen. Mlglicherweise braucht aber sonst jemand noch andere module

> Damit könnte man das "aufräumen"?
Ja, "make reuseconfig" ist jetzt gemergt. @PeterPawn die Script allerdings umbenannt nach tools/reuseconfig* Man könnte den Code des äußere Scriptes auch in die Makefile verschieben. Der Hilfetext ist dein Commitcomment: https://freetz-ng.github.io/freetz-ng/wiki/20_Advanced/make_targets.en.html

> Eine Meldung ist schon gut - muss das denn (sinnvollerweise) zum Abbruch führen?
Ja unbedingt. Sonst wird sie ignoriert und man bräuchte sie nicht :D

> paar Patches einfach in den Skat gedrückt wurde
Müsste jetzt gurgeln was das bedeutet. Falls du meinst dass da möglicherweise Patches fehlen: kann gut sein! Ich hab nur die von AVM genommen (Dateiname). Bislang gabs auch keine Problem... Bin froh dass es überhaupt läuft. Das ganze ist nicht so ganz mein Fachgebiet

> Ich verstehe immer noch nicht, wo Du da in #1 irgendetwas von "ARM" liest.
Ich auch nicht :)

> Optimierungen machen halt nur so lange Sinn, wie man tatsächlich die kleinsten Dateien der Welt erzeugen will
Für die alten 8 oder 16 MB war das aber nützlich, dürfte für die 48MB Filesystem Boxen egal sein. Gibt ja sogar ne doppelte libc.
Also den default des Strings von einer Bedingung abhängig machen? Gibt es FritzOS 7.xx+ für 16MB-flash Boxen?
 

Master SaMMy

Neuer User
Mitglied seit
20 Apr 2016
Beiträge
101
Punkte für Reaktionen
16
Punkte
18
Spracheinstellung von Ubuntu auf Deutsch umstellen

Dazu installieren wird die Sprachen.
sudo apt install locales

Wir können uns die aktuellen Einstellung ansehen.
locale -a

Sollte die Sprache „Deutsch“ mit UTF-8 nicht nicht erzeugt sein, so sollten wir es jetzt vornehmen.
sudo locale-gen de_DE.UTF-8

Die Einstellungen für die Sprache können wir mit einem grafischen Tool einfach ändern.
sudo dpkg-reconfigure locales

Nach der Umstellung sollten nur Einträg welche ausgewählt wurden in der Datei enthalten sein.
cat /etc/locale.gen
de_DE.UTF-8 UTF-8

Für unsere Umgebung müssen wir ggf. noch die Einstellungen hinterlegen.
sudo nano /etc/default/locale
LANG=de_DE.UTF-8
LANGUAGE=de_DE.UTF-8
LC_MESSAGES=de_DE.UTF-8

sudo nano /etc/environment
LC_ALL=de_DE.UTF-8
LANG=de_DE.UTF-8

Überflüssige Sprachen können entfernt werden und im Anschluss neu generiert werden.
sudo locale-gen
 
  • Like
Reaktionen: gismotro

Master SaMMy

Neuer User
Mitglied seit
20 Apr 2016
Beiträge
101
Punkte für Reaktionen
16
Punkte
18
wenn man zb mc nutzt ist es in Deutsch oder wenn df. Und einige wollen es vielleich auch gerne lieber in Deutsch haben
 
  • Like
Reaktionen: gismotro

Zurzeit aktive Besucher

Keine Mitglieder online.
3CX

Statistik des Forums

Themen
236,196
Beiträge
2,072,361
Mitglieder
357,414
Neuestes Mitglied
CaptainNem0