.titleBar { margin-bottom: 5px!important; }

[Frage] Freetz für 3170

Dieses Thema im Forum "Freetz" wurde erstellt von Coolzero82, 17 Aug. 2017.

  1. Coolzero82

    Coolzero82 Mitglied

    Registriert seit:
    24 Sep. 2013
    Beiträge:
    274
    Zustimmungen:
    1
    Punkte für Erfolge:
    18
    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
     
  2. PeterPawn

    PeterPawn IPPF-Promi

    Registriert seit:
    10 Mai 2006
    Beiträge:
    9,711
    Zustimmungen:
    257
    Punkte für Erfolge:
    83
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    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.
     
  3. Coolzero82

    Coolzero82 Mitglied

    Registriert seit:
    24 Sep. 2013
    Beiträge:
    274
    Zustimmungen:
    1
    Punkte für Erfolge:
    18
    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
    
     
  4. PeterPawn

    PeterPawn IPPF-Promi

    Registriert seit:
    10 Mai 2006
    Beiträge:
    9,711
    Zustimmungen:
    257
    Punkte für Erfolge:
    83
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    make download-clean
     
  5. Coolzero82

    Coolzero82 Mitglied

    Registriert seit:
    24 Sep. 2013
    Beiträge:
    274
    Zustimmungen:
    1
    Punkte für Erfolge:
    18
    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
     
  6. PeterPawn

    PeterPawn IPPF-Promi

    Registriert seit:
    10 Mai 2006
    Beiträge:
    9,711
    Zustimmungen:
    257
    Punkte für Erfolge:
    83
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    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.
     
  7. Coolzero82

    Coolzero82 Mitglied

    Registriert seit:
    24 Sep. 2013
    Beiträge:
    274
    Zustimmungen:
    1
    Punkte für Erfolge:
    18
    Hi, nein brauche ich nicht, ist aber auch kein replaced ausgewählt in make menuconfig.....................
     
  8. PeterPawn

    PeterPawn IPPF-Promi

    Registriert seit:
    10 Mai 2006
    Beiträge:
    9,711
    Zustimmungen:
    257
    Punkte für Erfolge:
    83
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    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.
     
  9. Coolzero82

    Coolzero82 Mitglied

    Registriert seit:
    24 Sep. 2013
    Beiträge:
    274
    Zustimmungen:
    1
    Punkte für Erfolge:
    18
    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
    
     
  10. PeterPawn

    PeterPawn IPPF-Promi

    Registriert seit:
    10 Mai 2006
    Beiträge:
    9,711
    Zustimmungen:
    257
    Punkte für Erfolge:
    83
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    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).
     
  11. Coolzero82

    Coolzero82 Mitglied

    Registriert seit:
    24 Sep. 2013
    Beiträge:
    274
    Zustimmungen:
    1
    Punkte für Erfolge:
    18
    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
    
     
  12. PeterPawn

    PeterPawn IPPF-Promi

    Registriert seit:
    10 Mai 2006
    Beiträge:
    9,711
    Zustimmungen:
    257
    Punkte für Erfolge:
    83
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    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.
     
  13. qwertz.asdfgh

    qwertz.asdfgh IPPF-Promi

    Registriert seit:
    18 Feb. 2011
    Beiträge:
    4,399
    Zustimmungen:
    39
    Punkte für Erfolge:
    48
    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
     
  14. Pokemon20021

    Pokemon20021 Mitglied

    Registriert seit:
    9 Aug. 2016
    Beiträge:
    602
    Zustimmungen:
    5
    Punkte für Erfolge:
    18
    @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.
     
  15. PeterPawn

    PeterPawn IPPF-Promi

    Registriert seit:
    10 Mai 2006
    Beiträge:
    9,711
    Zustimmungen:
    257
    Punkte für Erfolge:
    83
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    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).
     
  16. Pokemon20021

    Pokemon20021 Mitglied

    Registriert seit:
    9 Aug. 2016
    Beiträge:
    602
    Zustimmungen:
    5
    Punkte für Erfolge:
    18
    es fehlen hier Inputs seitens TE:
    weiterer Hinweis für Tools bzw. Toolchain-Troubleshooting:
    auch Angaben zur Build-Umgebung:
    LINUX-Distribution, -Version,
    sind hilfreich.

    nur so kommt man aus dem "Ratespiel" heraus.
     
  17. koyaanisqatsi

    koyaanisqatsi IPPF-Promi

    Registriert seit:
    24 Jan. 2013
    Beiträge:
    9,920
    Zustimmungen:
    53
    Punkte für Erfolge:
    48
    Moin

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

    PeterPawn IPPF-Promi

    Registriert seit:
    10 Mai 2006
    Beiträge:
    9,711
    Zustimmungen:
    257
    Punkte für Erfolge:
    83
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    @koy:
    Das sollte von der Freetz-Toolchain schon ganz am Beginn abgefangen werden.
     
  19. Coolzero82

    Coolzero82 Mitglied

    Registriert seit:
    24 Sep. 2013
    Beiträge:
    274
    Zustimmungen:
    1
    Punkte für Erfolge:
    18
    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