[Frage] Freetz für 3170

Coolzero82 · 17 Aug 2017

Hallo,
beim Build für eine Image für die 3170 mit dem aktuellen freetz Trunk bekomme ich diesen Fehler:

Code:

ERROR: Build failed.
make/wget/wget.mk:70: die Regel für Ziel „source/target-mipsel_gcc-4.6.4_uClibc-0.9.28/wget-1.19.1/src/wget“ scheiterte
make: *** [source/target-mipsel_gcc-4.6.4_uClibc-0.9.28/wget-1.19.1/src/wget] Fehler 1

Einer eine idee was falsch läuft

Danke

PeterPawn · 18 Aug 2017

Ja, da kann offenbar das "wget" als gewähltes Paket nicht gebaut werden ... aber das kannst Du sicherlich selbst lesen.

Der Grund dafür sollte aber vor dem "ERROR: Build failed." stehen und davon sieht man leider nichts.

Coolzero82 · 30 Aug 2017

Hi, bin grad erst dazu gekommen es nochmal zu versuchen, nun bekomme ich diesen Fehler meim make

Code:

 make
---> package/fuse-kernel-module: preparing... mkdir -p source/target-mipsel_gcc-4.6.4_uClibc-0.9.28/fuse-kernel-module-2.7.6; tools/gunzip -c dl/fuse-2.7.6.tar.gz | tools/tar-gnu -C source/target-mipsel_gcc-4.6.4_uClibc-0.9.28/fuse-kernel-module-2.7.6 -x --strip-components=2 fuse-2.7.6/kernel;
gunzip: invalid magic
tools/tar-gnu: This does not look like a tar archive
tools/tar-gnu: fuse-2.7.6/kernel: Not found in archive
tools/tar-gnu: Exiting with failure status due to previous errors
make/fuse-kernel-module/fuse-kernel-module.mk:22: die Regel für Ziel „source/target-mipsel_gcc-4.6.4_uClibc-0.9.28/fuse-kernel-module-2.7.6/.unpacked“ scheiterte
make: *** [source/target-mipsel_gcc-4.6.4_uClibc-0.9.28/fuse-kernel-module-2.7.6/.unpacked] Fehler 2

PeterPawn · 30 Aug 2017

make download-clean

Coolzero82 · 30 Aug 2017

Dann kommt anschließend beim makle

Code:

    applying patch file tools/make/yourfritz-host/patches/110-avm_kernel_config-Makefile.freetz.patch
    The next patch would create the file avm_kernel_config/Makefile.freetz,
    which already exists!  Applying it anyway.
    patching file avm_kernel_config/Makefile.freetz
    Hunk #1 FAILED at 1.
    1 out of 1 hunk FAILED -- saving rejects to file avm_kernel_config/Makefile.freetz.rej
    ----------------------------------------------------------------------
ERROR: modpatch: Error in patch-file tools/make/yourfritz-host/patches/110-avm_kernel_config-Makefile.freetz.patch
tools/make/yourfritz-host/yourfritz-host.mk:20: die Regel für Ziel „/home/thomas/TB_3_1/source/host-tools/yourfritz-825ba59556/.unpacked“ scheiterte
make: *** [/home/thomas/TB_3_1/source/host-tools/yourfritz-825ba59556/.unpacked] Fehler 2

Auch ein make clean, mit anschließendem make menconfig und dann make bringt keine besserung

PeterPawn · 30 Aug 2017

Da habe ich keine Ahnung von, da halte ich mich raus ... aber brauchst Du wirklich einen eigenen Kernel? Wenn nicht, sollte das Abschalten von "replace kernel" als Workaround funktionieren, weil dann eigentlich auch nichts vom "avm_kernel_config"-Kram gebraucht wird.

Coolzero82 · 31 Aug 2017

Hi, nein brauche ich nicht, ist aber auch kein replaced ausgewählt in make menuconfig.....................

PeterPawn · 31 Aug 2017

Dann gäbe es - zumindst in der Theorie - auch keinen Grund, warum die Toolchain da die Teile für "avm_kernel_config" bauen sollte ... aber wie gesagt, da halte ich mich raus.

Als einzigen Tipp könnte ich Dir noch ans Herz legen, die Datei "tools/make/yourfritz-host/patches/110-avm_kernel_config-Makefile.freetz.patch" so umzubenennen, daß sie nicht auf ".patch" endet. Wenn dann das "make" über das Bauen des "avm_kernel_config"-Files hinwegkommt, brauchst Du Dir - ohne "replace kernel" - auch keine Sorgen um mögliche Konsequenzen für das entstehende Image machen.

Coolzero82 · 31 Aug 2017

Ja das verstehe ich halt auch nicht. nachdem ich den "Patch" umbenannt habe, läuft der build deutlich weiter, bis hier hin:

Code:

make[5]: Leaving directory '/home/thomas/TB_3_1/source/target-mipsel_gcc-4.6.4_uClibc-0.9.28/wget-1.19.1/lib'
make[4]: Leaving directory '/home/thomas/TB_3_1/source/target-mipsel_gcc-4.6.4_uClibc-0.9.28/wget-1.19.1/lib'
make[3]: Leaving directory '/home/thomas/TB_3_1/source/target-mipsel_gcc-4.6.4_uClibc-0.9.28/wget-1.19.1/lib'
Making all in src
make[3]: Entering directory '/home/thomas/TB_3_1/source/target-mipsel_gcc-4.6.4_uClibc-0.9.28/wget-1.19.1/src'
make  all-am
make[4]: Entering directory '/home/thomas/TB_3_1/source/target-mipsel_gcc-4.6.4_uClibc-0.9.28/wget-1.19.1/src'
  CC       url.o
  CC       warc.o
url.c: In function 'convert_fname':
url.c:1553:3: error: unknown type name 'iconv_t'
url.c:1565:14: error: 'iconv_t' undeclared (first use in this function)
url.c:1565:14: note: each undeclared identifier is reported only once for each function it appears in
Makefile:1647: recipe for target 'url.o' failed
make[4]: *** [url.o] Error 1
make[4]: *** Waiting for unfinished jobs....
make[4]: Leaving directory '/home/thomas/TB_3_1/source/target-mipsel_gcc-4.6.4_uClibc-0.9.28/wget-1.19.1/src'
Makefile:1464: recipe for target 'all' failed
make[3]: *** [all] Error 2
make[3]: Leaving directory '/home/thomas/TB_3_1/source/target-mipsel_gcc-4.6.4_uClibc-0.9.28/wget-1.19.1/src'
Makefile:1454: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory '/home/thomas/TB_3_1/source/target-mipsel_gcc-4.6.4_uClibc-0.9.28/wget-1.19.1'
Makefile:1410: die Regel für Ziel „all“ scheiterte
make[1]: *** [all] Fehler 2
make[1]: Verzeichnis „/home/thomas/TB_3_1/source/target-mipsel_gcc-4.6.4_uClibc-0.9.28/wget-1.19.1“ wird verlassen

ERROR: Build failed.
make/wget/wget.mk:70: die Regel für Ziel „source/target-mipsel_gcc-4.6.4_uClibc-0.9.28/wget-1.19.1/src/wget“ scheiterte
make: *** [source/target-mipsel_gcc-4.6.4_uClibc-0.9.28/wget-1.19.1/src/wget] Fehler 1

PeterPawn · 31 Aug 2017

Dann laß halt auch "wget" erst einmal aus - braucht man ohnehin nur äußerst selten, die neuen BusyBox-Versionen erlauben auch HTTPS-Downloads mit "wget", solange "openssl" auch existiert und "s_client" nutzbar ist. Erst wenn das GNU-wget irgendwelche Optionen unterstützt, die man unbedingt benötigt, braucht man auch dieses "wget".

Wobei ich da ohnehin nicht durchblicke ... wenn das eine 3170 ist und irgendeine uralte 04.xx-Firmware, warum wird dann überhaupt "avm_kernel_config" benutzt? Das ist m.E. vielleicht dann notwendig, wenn es sich um ein System mit einem 3er-Kernel handelt ... bis inkl. 2.6 reichte es vollkommen aus, den Aufruf der entsprechenden "init"-Funktion in irgendeinem File einfach auszukommentieren. Ich würde nicht einmal darauf wetten, daß in einer so alten uClibc überhaupt die "iconv"-Funktionen enthalten waren - dann wäre es zumindest kein Wunder, wenn die zugehörigen Header-Files auch nicht gefunden werden.

Bist Du wirklich sicher, daß Du da eine "frische" Konfigurationsdatei verwendest und nicht irgendwelche älteren Geschichten zusammenmixt? Das ist kein wirklicher Ausdruck des Mißtrauens ... wenn die Antwort eindeutig "ja" ist, muß man vielleicht am Ende konstatieren, daß der Trunk nicht mehr für die uralten Versionen funktioniert ... zumindest nicht so, wie er im Moment dann irgendwelche Abhängigkeiten auflöst.

Immerhin stammt die Basis-Firmware für die 3170 aus dem Jahr 2008 - damals war gerade mal wget 1.11 aktuell und ob damals (und in der alten 4.6.4-Toolchain) die iconv-Functionen tatsächlich schon in der uClibc vorhanden oder aktiviert waren (also die C-Library mit "locale"-Support verwendet wurde), muß man wohl auch erst mal erkunden.

Ich weiß ja nicht, wofür Du diese Firmware brauchst ... aber das wäre wohl mal einer der wenigen Fälle, wo man einen Stable-Zweig verwenden sollte - wenn hier "avm_kernel_config" angefaßt wird, ist es wohl der Trunk.

Wobei da dann vermutlich wieder ältere Bugs ebenfalls Einzug halten ... spätestens dann, wenn alte Freetz-Pakete verwendet werden.

Aber - ich wiederhole es noch einmal - betrachte das bitte nur als meine persönliche Ansicht ... Freetz ist eigentlich "nicht mein Tisch" und wie weit jetzt neuere Versionen irgendwelcher Pakete auch für alte Stable-Zweige verwendet werden, weiß ich nicht wirklich (und will ich nicht erkunden). Durchaus denkbar, daß da auch immer die neuesten Quelltexte herangezogen werden ... dann sind aber solche Probleme wie hier absehbar, wenn irgendein Paket zusätzliche Abhängigkeiten entwickelt, die vor 9 Jahren noch nicht bestanden und wo die vorausgesetzten Bibliotheken vielleicht gar nicht erstellt wurden oder werden.

Wenn man eine ".config" für Freetz oder gar die für die uClibc hätte, könnte man zumindest zielgerichteter spekulieren ... aber deshalb baue ich mir jetzt nicht selbst eine solche Freetz-Toolchain (dauert mir zu lange und es wüßte ja ohnehin niemand, was Du da nun bei Dir eingestellt hast).

Coolzero82 · 3 Sep 2017

Also das weglassen von wget lässt den prozess jetzt deutlich weiter laufen, allerdings gibt es immer noch einen Fehler:

Code:

installing mod base
installing libs
  ld_uClibc .........................    9.10 Kb
  libcrypt ..........................    6.11 Kb
  libctlmgr .........................    1.71 Kb
  libdl .............................    3.56 Kb
  libgcc_s ..........................   20.49 Kb
  libm ..............................   30.87 Kb
  libpthread ........................   20.76 Kb
  librt .............................    1.59 Kb
  libuClibc .........................  128.53 Kb
  checking uClibc version
    ... used by AVM ...... 0.9.28
    ... used by Freetz ... 0.9.28
installing busybox
  replacing busybox
ERROR: cannot find busybox replacement
Makefile:310: die Regel für Ziel „firmware-nocompile“ scheiterte
make: *** [firmware-nocompile] Fehler 1

Hab es dann auch mal mit einem frisch ausgecheckten stable 2.0 versucht, dies Bricht aber auch mit einem Fehler ab.

Code:

     INFO("file %s, uncompressed size %lld bytes, %s\n", filename, buf.st_size, duplicate_file ? "DUPLICATE" : "");
      ^~~~
mksquashfs-lzma.o: In Funktion `linux_opendir':
/home/thomas/stable2/source/host-tools/squashfs2.2-r2/squashfs-tools/mksquashfs-lzma.c:1311: Nicht definierter Verweis auf `add_dir_entry'
mksquashfs-lzma.o: In Funktion `encomp_opendir':
/home/thomas/stable2/source/host-tools/squashfs2.2-r2/squashfs-tools/mksquashfs-lzma.c:1326: Nicht definierter Verweis auf `add_dir_entry'
/home/thomas/stable2/source/host-tools/squashfs2.2-r2/squashfs-tools/mksquashfs-lzma.c:1343: Nicht definierter Verweis auf `add_dir_entry'
mksquashfs-lzma.o: In Funktion `single_opendir':
/home/thomas/stable2/source/host-tools/squashfs2.2-r2/squashfs-tools/mksquashfs-lzma.c:1358: Nicht definierter Verweis auf `add_dir_entry'
/home/thomas/stable2/source/host-tools/squashfs2.2-r2/squashfs-tools/mksquashfs-lzma.c:1378: Nicht definierter Verweis auf `add_dir_entry'
collect2: error: ld returned 1 exit status
Makefile:10: die Regel für Ziel „mksquashfs-lzma“ scheiterte
make[1]: *** [mksquashfs-lzma] Fehler 1
tools/make/squashfs.mk:25: die Regel für Ziel „/home/thomas/stable2/source/host-tools/squashfs2.2-r2/squashfs-tools/mksquashfs-lzma“ scheiterte
make: *** [/home/thomas/stable2/source/host-tools/squashfs2.2-r2/squashfs-tools/mksquashfs-lzma] Fehler 2

PeterPawn · 3 Sep 2017

Ja, gut ... das mit der Stable-Version war auch nur so eine Idee - wenn Du keinen Fehler gemacht hast, ist das vielleicht wirklich nicht mehr lauffähig. Da soll jedenfalls das Programm zum Packen eines (alten) SquashFS-Dateisystems übersetzt werden (warum das für die 2.2 erfolgt, weiß ich zwar nicht, aber ggf. waren die alten Versionen - und wir reden hier ja von einer (AVM-)Version< 05.xx - noch SquasFS2-Images) und da enthalten die Quellen jetzt eine bestimmte Funktion nicht. Das ist entweder auf fehlende Dateien zurückzuführen oder es wurde halt sehr lange nicht mit der Stable-Version getestet. Ich habe zwar mal spaßeshalber die Stable-Version aus dem SVN ausgecheckt, weiß aber noch nicht, ob ich zu einem eigenen Test kommen werde.

Ansonsten hat der Fehler im Trunk seine Ursachen deutlich davor, denn an dieser Stelle: http://freetz.org/browser/trunk/fwmod#L1112 kann eigentlich das zugrundeliegende Problem nur eine fehlende "busybox" im Paketverzeichnis sein und die kann da eigentlich nur fehlen, wenn sie (a) nicht richtig gebaut oder (b) nicht richtig kopiert/installiert wurde. Beides sollte bereits davor mit einer Fehlermeldung quittiert werden.

Einzige Diagnose-Mlöglichkeit, die mir einfällt:

make busybox-clean
make busybox-precompiled

und für diejenigen, die immer wieder Probleme haben und dann keinen Zugriff auf ältere Zeilen aus dem "make"-Protokoll haben, hat Gott (oder es war doch irgendjemand, der sich mit Freetz befaßte) das Skript "fmake" bereitgestellt. Wie man das verwendet, steht im Wiki oder in der Hilfe des Skripts und dann hat man auch keine Probleme mehr, wenn man bei einem Fehler mal etwas weiter in die Vergangenheit blicken muß (oder will).

PS: Mittlerweile ist dann doch ein "make" für den ausgecheckten Stable-2.0-Branch bei mir durchgelaufen, wobei ich ausschließlich in "make menuconfig" das richtige Modell (3170) eingestellt und ansonsten nichts geändert habe. Da eigentlich kein zusätzlich ausgewähltes Paket Auswirkungen auf die "host-tools" haben dürfte (wo es bei Dir ja dann klemmt), liegt es vielleicht doch (a) an Änderungen Deinerseits in der Konfiguration oder (b) an Deinem Build-Host. Vielleicht gehst Du ja doch einfach mal systematisch vor und testest in kleineren Schritten. Das einzige Problem, was das von mir erzeugte Image hat, sind 200 KB zuviel - da ich das Gerät nicht habe, ist mir das aber egal.

qwertz.asdfgh · 3 Sep 2017

Das hatte mich jetzt mal neugierig gemacht und habe daher einfach mal "Just-for-Fun" versucht ein Freetz-Image für die 3170 zu bauen, mit einem frisch ausgecheckten Freetz-Trunk:

Code:

[...]

STEP 3: PACK
  checking for left over Subversion directories
  integrate freetz info file into image
packing var.tar
creating filesystem image (SquashFS2-lzma)
  SquashFS block size: 64 kB (65536 bytes)
merging kernel image
  kernel image size: 3.3 MB, max 3.7 MB, free 0.4 MB (379648 bytes)
adding checksum to kernel.image
packing images/3170_04.58-freetz-devel-14388.de_20170903-183124.image
  image file size: 3.6 MB
done.

FINISHED

Wie man sieht gab es keine Probleme.

Also habe ich Spaßeshalber noch GNU Wget mit rein genommen:

Code:

[...]
make[4]: *** [url.o] Error 1
make[4]: *** Waiting for unfinished jobs....
make[4]: Leaving directory `/home/[...]/freetz/freetz-trunk_r14388_3170-test/source/target-mipsel_gcc-4.6.4_uClibc-0.9.28/wget-1.19.1/src'
make[3]: *** [all] Error 2
make[3]: Leaving directory `/home/[...]/freetz/freetz-trunk_r14388_3170-test/source/target-mipsel_gcc-4.6.4_uClibc-0.9.28/wget-1.19.1/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/[...]/freetz/freetz-trunk_r14388_3170-test/source/target-mipsel_gcc-4.6.4_uClibc-0.9.28/wget-1.19.1'
make[1]: *** [all] Fehler 2
make[1]: Verzeichnis »/home/[...]/freetz/freetz-trunk_r14388_3170-test/source/target-mipsel_gcc-4.6.4_uClibc-0.9.28/wget-1.19.1« wird verlassen

ERROR: Build failed.
make: *** [source/target-mipsel_gcc-4.6.4_uClibc-0.9.28/wget-1.19.1/src/wget] Fehler 1

Siehe da, da gibt es ein Problem. Also GNU Wget wieder heraus genommen (ohne "make config-clean-deps"):

Code:

[...]
STEP 3: PACK
  checking for left over Subversion directories
  integrate freetz info file into image
packing var.tar
creating filesystem image (SquashFS2-lzma)
  SquashFS block size: 64 kB (65536 bytes)
merging kernel image
  kernel image size: 3.3 MB, max 3.7 MB, free 0.4 MB (379648 bytes)
adding checksum to kernel.image
packing images/3170_04.58-freetz-devel-14388.de_20170903-184349.image
  image file size: 3.6 MB
done.

FINISHED

Geht wieder...

Ich kann das Problem also nur zum Teil nachstellen.

Hier mal die letzten Zeilen vom Versuch mit GNU Wget wo es fehlschlägt:

Code:

[...]
Trying libraries: crypt m
 Library crypt is not needed, excluding it
 Library m is not needed, excluding it
Final link with: <none>
make[1]: Verzeichnis »/home/[...]/freetz/freetz-trunk_r14388_3170-test/source/target-mipsel_gcc-4.6.4_uClibc-0.9.28/busybox-1.24.2« wird verlassen
mkdir -p packages/target-mipsel_gcc-4.6.4_uClibc-0.9.28/busybox/; cp source/target-mipsel_gcc-4.6.4_uClibc-0.9.28/busybox-1.24.2/busybox packages/target-mipsel_gcc-4.6.4_uClibc-0.9.28/busybox/busybox; /home/[...]/freetz/freetz-trunk_r14388_3170-test/toolchain/build/mipsel_gcc-4.6.4_uClibc-0.9.28/mipsel-linux-uclibc/bin/mipsel-linux-uclibc-strip --remove-section={.comment,.note,.pdr} packages/target-mipsel_gcc-4.6.4_uClibc-0.9.28/busybox/busybox;
cmd() { PATH="/home/[...]/freetz/freetz-trunk_r14388_3170-test/toolchain/build/mipsel_gcc-4.6.4_uClibc-0.9.28/mipsel-linux-uclibc/bin:/home/[...]/freetz/freetz-trunk_r14388_3170-test/toolchain/build/mipsel_gcc-3.4.6/mipsel-unknown-linux-gnu/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games" LD_RUN_PATH="/usr/lib/freetz" FREETZ_LIBRARY_DIR="/usr/lib/freetz" make -j2  "$@"  || { printf "\n\\033[33m%s\\033[m\n" "ERROR: Build failed.";  exit 1; } }; 	if [ -e source/.echo_item_start -a ! -e source/.echo_item_build ]; then echo -n "building... "; touch source/.echo_item_build; fi; cmd -C source/target-mipsel_gcc-4.6.4_uClibc-0.9.28/busybox-1.24.2 \
		CC="/home/[...]/freetz/freetz-trunk_r14388_3170-test/toolchain/build/mipsel_gcc-4.6.4_uClibc-0.9.28/mipsel-linux-uclibc/bin/mipsel-linux-uclibc-gcc" CROSS_COMPILE="/home/[...]/freetz/freetz-trunk_r14388_3170-test/toolchain/build/mipsel_gcc-4.6.4_uClibc-0.9.28/mipsel-linux-uclibc/bin/mipsel-linux-uclibc-" EXTRA_CFLAGS="-march=4kc -mtune=4kc -msoft-float -Os -pipe -Wa,--trap -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64" ARCH="mips" \
		busybox.links
make[1]: Verzeichnis »/home/[...]/freetz/freetz-trunk_r14388_3170-test/source/target-mipsel_gcc-4.6.4_uClibc-0.9.28/busybox-1.24.2« wird betreten
make[1]: Verzeichnis »/home/[...]/freetz/freetz-trunk_r14388_3170-test/source/target-mipsel_gcc-4.6.4_uClibc-0.9.28/busybox-1.24.2« wird verlassen
touch -c source/target-mipsel_gcc-4.6.4_uClibc-0.9.28/busybox-1.24.2/busybox.links
cat source/target-mipsel_gcc-4.6.4_uClibc-0.9.28/busybox-1.24.2/busybox.links | sed -r -e 's,(blkid|wget),\1-busybox,g' > packages/target-mipsel_gcc-4.6.4_uClibc-0.9.28/busybox/busybox.links
done.
cmd() { PATH="/home/[...]/freetz/freetz-trunk_r14388_3170-test/toolchain/build/mipsel_gcc-4.6.4_uClibc-0.9.28/mipsel-linux-uclibc/bin:/home/[...]/freetz/freetz-trunk_r14388_3170-test/toolchain/build/mipsel_gcc-3.4.6/mipsel-unknown-linux-gnu/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games" LD_RUN_PATH="/usr/lib/freetz" FREETZ_LIBRARY_DIR="/usr/lib/freetz" make -j2  "$@"  || { printf "\n\\033[33m%s\\033[m\n" "ERROR: Build failed.";  exit 1; } }; 	if [ -e source/.echo_item_start -a ! -e source/.echo_item_build ]; then echo -n "building... "; touch source/.echo_item_build; fi; cmd -C source/target-mipsel_gcc-4.6.4_uClibc-0.9.28/wget-1.19.1 \
		EXTRA_CFLAGS="-ffunction-sections -fdata-sections" \
		EXTRA_LDFLAGS="-Wl,--gc-sections" \
		EXTRA_LIBS=""
make[1]: Verzeichnis »/home/[...]/freetz/freetz-trunk_r14388_3170-test/source/target-mipsel_gcc-4.6.4_uClibc-0.9.28/wget-1.19.1« wird betreten
make  all-recursive
make[2]: Entering directory `/home/[...]/freetz/freetz-trunk_r14388_3170-test/source/target-mipsel_gcc-4.6.4_uClibc-0.9.28/wget-1.19.1'
Making all in lib
make[3]: Entering directory `/home/[...]/freetz/freetz-trunk_r14388_3170-test/source/target-mipsel_gcc-4.6.4_uClibc-0.9.28/wget-1.19.1/lib'
make  all-recursive
make[4]: Entering directory `/home/[...]/freetz/freetz-trunk_r14388_3170-test/source/target-mipsel_gcc-4.6.4_uClibc-0.9.28/wget-1.19.1/lib'
make[5]: Entering directory `/home/[...]/freetz/freetz-trunk_r14388_3170-test/source/target-mipsel_gcc-4.6.4_uClibc-0.9.28/wget-1.19.1/lib'
make[5]: Nothing to be done for `all-am'.
make[5]: Leaving directory `/home/[...]/freetz/freetz-trunk_r14388_3170-test/source/target-mipsel_gcc-4.6.4_uClibc-0.9.28/wget-1.19.1/lib'
make[4]: Leaving directory `/home/[...]/freetz/freetz-trunk_r14388_3170-test/source/target-mipsel_gcc-4.6.4_uClibc-0.9.28/wget-1.19.1/lib'
make[3]: Leaving directory `/home/[...]/freetz/freetz-trunk_r14388_3170-test/source/target-mipsel_gcc-4.6.4_uClibc-0.9.28/wget-1.19.1/lib'
Making all in src
make[3]: Entering directory `/home/[...]/freetz/freetz-trunk_r14388_3170-test/source/target-mipsel_gcc-4.6.4_uClibc-0.9.28/wget-1.19.1/src'
make  all-am
make[4]: Entering directory `/home/[...]/freetz/freetz-trunk_r14388_3170-test/source/target-mipsel_gcc-4.6.4_uClibc-0.9.28/wget-1.19.1/src'
  CC       url.o
  CC       warc.o
url.c: In function 'convert_fname':
url.c:1553:3: error: unknown type name 'iconv_t'
url.c:1565:14: error: 'iconv_t' undeclared (first use in this function)
url.c:1565:14: note: each undeclared identifier is reported only once for each function it appears in
make[4]: *** [url.o] Error 1
make[4]: *** Waiting for unfinished jobs....
make[4]: Leaving directory `/home/[...]/freetz/freetz-trunk_r14388_3170-test/source/target-mipsel_gcc-4.6.4_uClibc-0.9.28/wget-1.19.1/src'
make[3]: *** [all] Error 2
make[3]: Leaving directory `/home/[...]/freetz/freetz-trunk_r14388_3170-test/source/target-mipsel_gcc-4.6.4_uClibc-0.9.28/wget-1.19.1/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/[...]/freetz/freetz-trunk_r14388_3170-test/source/target-mipsel_gcc-4.6.4_uClibc-0.9.28/wget-1.19.1'
make[1]: *** [all] Fehler 2
make[1]: Verzeichnis »/home/[...]/freetz/freetz-trunk_r14388_3170-test/source/target-mipsel_gcc-4.6.4_uClibc-0.9.28/wget-1.19.1« wird verlassen

ERROR: Build failed.
make: *** [source/target-mipsel_gcc-4.6.4_uClibc-0.9.28/wget-1.19.1/src/wget] Fehler 1

Pokemon20021 · 3 Sep 2017

@Coolzero82
Könntest Du Bitte die .config Datei dem Thread anhängen, dies wäre wichtig um das Problem zu reproduzieren und ggf. Hilfestellung geben.

PeterPawn · 3 Sep 2017

Da dürfte meine Vermutung in die Richtung des fehlenden "locale"-Supports in der alten Toolchain (alter Compiler, alte uClibc 0.9.28 ... man müßte erst mal prüfen, ob die überhaupt "locale support" hatte) an Wahrscheinlichkeit gewinnen ... aber das Fehlen des BusyBox.-Files beim Installationsversuch kann ich mir fast nur noch mit falscher "umask" erklären, wo dann die Leserechte im "fakeroot" (was ja von "fwmod" verwendet wird) fehlen. Alles andere müßte lange vorher schon krachen ... es kann aber auch wieder irgendein alter "fakeroot"-Cache sein, der den tatsächlichen Dateisystem-Inhalt falsch wiedergibt (irgendwo gab es da - iirc, was nicht sein muß - ein Problem, was auch mir selbst immer wieder beim Entpacken/Packen für die 7270v3 auf die Füße gefallen ist, wenn ich das mal mit "fwmod" versucht habe).

Pokemon20021 · 3 Sep 2017

es fehlen hier Inputs seitens TE:

gismotro schrieb:
Wenn Du einen neuen Thread eröffnest sollte folgendes in deinem Thread zu finden sein bzw. in Ihm enthalten sein:

a.) Um welche Box geht es ( Bezeichnung der FritzBox ( z.B. 7141, 7170, 7270-V1 oder 7270-V2, u.s.w. ))
b.) Wie hast Du versucht das Image zu bauen ( Freetz-1.1.2, stabil-branch oder Freetz-Trunk )
c.) Welche Firmware / Labor-Version wolltest Du benutzen
d.) Welche Firmware war vor dem Flashen auf der Box
e.) Welche Fehlermeldung wurde dir wärend des Bauvorganges angezeigt.

Wichtig: Auf jeden Fall muß du die .config an den neuen Thread anhängen.

weiterer Hinweis für Tools bzw. Toolchain-Troubleshooting:

PeterPawn schrieb:
bei Problemen mit der Freetz-Toolchain bitte das mit "fmake" erzeugte Protokoll anhängen und auch sicherstellen, daß in der Freetz-Konfiguration die "verbosity" auf "2" gestellt ist (oder "3", wobei "2" ausreichen sollte und ich m.E. auch mit "3" schon Probleme gesehen habe, weil dann einige Pakete nicht so richtig wollten, da die "3" erst später eingeführt wurde und sie teilweise explizit auf "2" testen, damit sie eine erweiterte Protokollierung verwenden).

auch Angaben zur Build-Umgebung:
LINUX-Distribution, -Version,
sind hilfreich.

nur so kommt man aus dem "Ratespiel" heraus.

koyaanisqatsi · 4 Sep 2017

Moin

Coolzero82 schrieb:
Einer eine idee was falsch läuft

Nur weil ich es nirgendwo erkennen kann...
Welcher Linuxbenutzer wird verwendet ?
...doch nicht etwa: root ?

PeterPawn · 4 Sep 2017

@koy:
Das sollte von der Freetz-Toolchain schon ganz am Beginn abgefangen werden.

Coolzero82 · 4 Sep 2017

Hi,
ich bin jetzt mal hergegeangen, und habe eine neue VM mit Ubuntu 16.04 aufgesetzt und den trunk neu ausgecheckt, und siehe da, der build läuft durch, musste zwar einiges raus patchen, da das image ansonsten zu groß wäre, aber dann klappt der bau.
Wenn ich GNU Wget aktiviere scheitert der build wieder, nach dem deaktivieren klappt es aber dann.

Kann gerne aus der alten VM die configs anhängen wenn einer nach dem Fehler gucken will!?

Danke aufjedenfall mal für eure Hilfe, werd das IMage die Woche mal bei gelegenheit flashen, mal sehn ob dann auch ales läuft

[Frage] Freetz für 3170

Mitglied

IPPF-Urgestein

Mitglied

IPPF-Urgestein

Mitglied

IPPF-Urgestein

Mitglied

IPPF-Urgestein

Mitglied

IPPF-Urgestein

Mitglied

IPPF-Urgestein

IPPF-Promi

Mitglied

IPPF-Urgestein

Mitglied

IPPF-Urgestein

IPPF-Urgestein

Mitglied

Statistik des Forums