Ergebnis 1 bis 7 von 7

Thema: Build-Fehler bei PeterPawn's freetz-git-version

  1. #1
    IPPF-Einsteiger
    Registriert seit
    17.02.2016
    Beiträge
    23

    Build-Fehler bei PeterPawn's freetz-git-version

    Hallo
    ich bekomme einen Fehler beim build der freetz-version von peterpawn:

    tools/gunzip -c dl/squashfs4.3.tar.gz | tools/tar-gnu -C /home/freetz/freetz-master/source/host-tools -x
    set -e; shopt -s nullglob; for i in tools/make/squashfs4-host/patches/*.patch; do tools/freetz_patch /home/freetz/freetz-master/source/host-tools/squashfs4.3 $i; done;
    applying patch file tools/make/squashfs4-host/patches/001-de03266983ceb62e5365aac84fcd3b2fd4d16e6f.upstream. patch
    patching file squashfs-tools/mksquashfs.c
    ----------------------------------------------------------------------
    applying patch file tools/make/squashfs4-host/patches/002-4f24381e7edc0a46cf10278e4597051ac697ec7c.upstream. patch
    patching file squashfs-tools/mksquashfs.c
    ----------------------------------------------------------------------
    applying patch file tools/make/squashfs4-host/patches/010-fix_segfault_in_tracing_code.patch
    patching file squashfs-tools/pseudo.c
    ----------------------------------------------------------------------
    applying patch file tools/make/squashfs4-host/patches/050-freetz_specific_xz_paths.patch
    patching file squashfs-tools/Makefile
    ----------------------------------------------------------------------
    applying patch file tools/make/squashfs4-host/patches/060-link_compression_libs_statically.patch
    patching file squashfs-tools/Makefile
    ----------------------------------------------------------------------
    applying patch file tools/make/squashfs4-host/patches/100-TARGET_FORMAT.patch
    The next patch would create the file squashfs-tools/_endian.h,
    which already exists! Applying it anyway.
    patching file squashfs-tools/_endian.h
    Hunk #1 FAILED at 1.
    1 out of 1 hunk FAILED -- saving rejects to file squashfs-tools/_endian.h.rej
    patching file squashfs-tools/Makefile
    patching file squashfs-tools/mksquashfs.c
    patching file squashfs-tools/read_fs.c
    patching file squashfs-tools/read_xattrs.c
    patching file squashfs-tools/squashfs_compat.h
    patching file squashfs-tools/squashfs_swap.h
    patching file squashfs-tools/swap.c
    patching file squashfs-tools/unsquashfs.c
    patching file squashfs-tools/unsquashfs.h
    patching file squashfs-tools/gzip_wrapper.h
    patching file squashfs-tools/lz4_wrapper.h
    patching file squashfs-tools/lzo_wrapper.h
    patching file squashfs-tools/xz_wrapper.h
    ----------------------------------------------------------------------
    ERROR: modpatch: Error in patch-file tools/make/squashfs4-host/patches/100-TARGET_FORMAT.patch
    make: *** [/home/freetz/freetz-master/source/host-tools/squashfs4.3/.unpacked] Fehler 2

    Ich verwende die virtualbox-version mit ubuntu 14.04.

    Ich habe bereits testweise squashfs4.3.tar.gz von Hand heruntergeladen mit demselben Ergebnis.

    Danke im voraus
    Eberhard

  2. #2
    IPPF Achttausend-VIP Avatar von PeterPawn
    Registriert seit
    10.05.2006
    Ort
    Berlin
    Beiträge
    8.147
    Warum willst Du die überhaupt aus meinem Fork nehmen und was sind die genauen Versionen? Es gibt zwar Unterschiede zwischen dem Fork und dem Freetz-Trunk, aber bei den SquashFS-Tools sollte das eigentlich alles synchron sein, nachdem @Gene die Möglichkeiten beim "NMI vector gap" und mit dem Offset nach einem event. vorhandenen Kernel und/oder Dummy-SQFS-Header nachgezogen hatte - außer ich habe inzwischen weitere Unterschiede verdrängt.

    Hier soll vom Patch offenbar eine Datei erstellt werden, die bereits existiert ... normalerweise würde ein "make squashfs4-host-dirclean" das wieder beheben. Woher die nun kommt (ein Überbleibsel dürfte sie ja nicht sein, wenn da vorher kein erfolgreiches "make" erfolgte, also steht sie vermutlich im Source-Paket), weiß ich auch nicht ... an dieser Stelle sollte aber der Trunk 1:1 mit dem Fork übereinstimmen; damit dürfte das kein "fork-spezifisches" Problem sein.

    Ansonsten müßte man halt mal wissen, was in der "originalen" "_endian.h" nun steht und was in der "reject"-Datei ...

  3. #3
    IPPF-Einsteiger
    Registriert seit
    17.02.2016
    Beiträge
    23
    original _endian.h
    ================================================== ===
    #ifndef SQUASHFS_ENDIAN_H
    #define SQUASHFS_ENDIAN_H

    #define SQUASHFS4_LE 0
    #define SQUASHFS4_BE 1
    #define AVM_BE 2

    #ifndef linux
    #define __BYTE_ORDER BYTE_ORDER
    #define __BIG_ENDIAN BIG_ENDIAN
    #define __LITTLE_ENDIAN LITTLE_ENDIAN
    #else
    #include <endian.h>
    #endif

    #if defined(TARGET_FORMAT) && TARGET_FORMAT == SQUASHFS4_LE
    #define TARGET_FORMAT_BYTE_ORDER __LITTLE_ENDIAN
    #elif defined(TARGET_FORMAT) && (TARGET_FORMAT == SQUASHFS4_BE || TARGET_FORMAT == AVM_BE)
    #define TARGET_FORMAT_BYTE_ORDER __BIG_ENDIAN
    #else
    #error "Invalid or no TARGET_FORMAT defined, it's expected to be either SQUASHFS4_LE (for little-endian), SQUASHFS4_BE (for big-endian) or AVM_BE (for AVM modified big-endian)"
    #endif

    #if !(defined(TARGET_FORMAT_BYTE_ORDER) && (TARGET_FORMAT_BYTE_ORDER == __LITTLE_ENDIAN || TARGET_FORMAT_BYTE_ORDER == __BIG_ENDIAN))
    #error "Invalid or no TARGET_FORMAT_BYTE_ORDER defined, it's expected to be either __LITTLE_ENDIAN or __BIG_ENDIAN"
    #endif

    #endif /* SQUASHFS_ENDIAN_H */
    ================================================== ============
    _endian.h.rej
    ================================================== ============
    --- /dev/null
    +++ squashfs-tools/_endian.h
    @@ -0,0 +1,27 @@
    +#ifndef SQUASHFS_ENDIAN_H
    +#define SQUASHFS_ENDIAN_H
    +
    +#define SQUASHFS4_LE 0
    +#define SQUASHFS4_BE 1
    +
    +#ifndef linux
    +#define __BYTE_ORDER BYTE_ORDER
    +#define __BIG_ENDIAN BIG_ENDIAN
    +#define __LITTLE_ENDIAN LITTLE_ENDIAN
    +#else
    +#include <endian.h>
    +#endif
    +
    +#if defined(TARGET_FORMAT) && TARGET_FORMAT == SQUASHFS4_LE
    +#define TARGET_FORMAT_BYTE_ORDER __LITTLE_ENDIAN
    +#elif defined(TARGET_FORMAT) && TARGET_FORMAT == SQUASHFS4_BE
    +#define TARGET_FORMAT_BYTE_ORDER __BIG_ENDIAN
    +#else
    +#error "Invalid or no TARGET_FORMAT defined, it's expected to be either SQUASHFS4_LE (for little-endian) or SQUASHFS4_BE (for big-endian)"
    +#endif
    +
    +#if !(defined(TARGET_FORMAT_BYTE_ORDER) && (TARGET_FORMAT_BYTE_ORDER == __LITTLE_ENDIAN || TARGET_FORMAT_BYTE_ORDER == __BIG_ENDIAN))
    +#error "Invalid or no TARGET_FORMAT_BYTE_ORDER defined, it's expected to be either __LITTLE_ENDIAN or __BIG_ENDIAN"
    +#endif
    +
    +#endif /* SQUASHFS_ENDIAN_H */
    ================================================== ======================

  4. #4
    IPPF Achttausend-VIP Avatar von PeterPawn
    Registriert seit
    10.05.2006
    Ort
    Berlin
    Beiträge
    8.147
    Muß man jetzt (nachdem Du offenbar in den "ansonsten"-Zweig ausgewichen bist) schlußfolgern, daß das Problem trotz "make dirclean" (ggf. auch nur für das einzelne Paket) weiterhin besteht? Woher kommt denn das verwendete Source-Archiv, wenn da bereits eine "_endian.h" enthalten ist? Da dort noch eine MD5-Prüfsumme verwendet wird und die nicht "pro Quelle", sondern nur "pro Paket" existiert, kann es eigentlich keine zwei unterschiedlichen Quell-Pakete geben.

    Der "Vergleich" der "reject"-Datei und des Originals war ja nur ultima ratio ... eigentlich dürfte - rein nach dem Aufbau des Patch-Files - in dem Source-Paket gar keine "_endian.h" enthalten sein. Daß es sich 1:1 um das "Ergebnis" des Patch-Files handelt, ist ja deutlich zu sehen ... also gab es da wohl zuvor bereits einen Build, bei dem das Patchen erfolgreich lief. Meines Wissens wird bei den "host tools" auch nicht jedesmal das Verzeichnis mit den Quellen gelöscht und neu ausgepackt, da gibt es die Abhängigkeit für das entsprechende Verzeichnis mit den Quellen nicht.

  5. #5
    IPPF-Einsteiger
    Registriert seit
    17.02.2016
    Beiträge
    23
    Sorry, ich bin noch nicht so erfahren mit der Art, hier zu posten.

    Ich bin nun über den Punkt _endian.h hinübergekommen, nun meldet make das nächste Patch-Problem:

    patching file squashfs-tools/unsquashfs.c
    Hunk #1 FAILED at 77.
    Hunk #2 succeeded at 176 (offset 5 lines).
    Hunk #3 succeeded at 428 (offset 5 lines).
    Hunk #4 succeeded at 556 (offset 5 lines).
    Hunk #5 succeeded at 603 (offset 5 lines).
    Hunk #6 FAILED at 635.
    Hunk #7 succeeded at 860 (offset 208 lines).
    Hunk #8 succeeded at 881 (offset 208 lines).
    Hunk #9 succeeded at 1779 (offset 208 lines).
    Hunk #10 succeeded at 2202 (offset 208 lines).
    Hunk #11 FAILED at 2651.
    Hunk #12 FAILED at 2715.
    Hunk #13 succeeded at 2965 with fuzz 1 (offset 235 lines).
    4 out of 13 hunks FAILED -- saving rejects to file squashfs-tools/unsquashfs.c.rej
    Hier ist unsquashfs.c.rej:
    Code:
    --- squashfs-tools/unsquashfs.c
    +++ squashfs-tools/unsquashfs.c
    @@ -77,6 +77,33 @@
     int inode_number = 1;
     int no_xattrs = XATTR_DEF;
     int user_xattrs = FALSE;
    +int scan_for_superblock = FALSE;
    +off_t superblock_offset = 0;
    +int has_ti_checksum = FALSE;
    +size_t image_size = 0;
    +int has_nmi_vector_gap = FALSE;
    +off_t nmi_vector_gap_start = 0;
    +int has_swapped_endianess = FALSE;
    +int split_read = FALSE;
    +
    +/*
    +- from AVM's code for MTD scanners
    +- static definition, because we need the gap
    +  size for each read operation behind the
    +  start of this data and it's not really a
    +  difference, if we copy it to another size_t
    +  variable or use it directly from the struct
    +  below
    +- the numeric members are in the endianess of
    +  the image and have to be swapped, if needed
    +*/
    +struct
    +{
    +        unsigned int firmware_length;
    +        unsigned int vector_gap;
    +        char vector_id[32];
    +} nmi_vector_location;
    +
    
     int exit_on_decompression_errors = FALSE;
     #define DECOMPRESSION_ERROR(s, args...)\
    @@ -635,16 +662,157 @@
     }
    
    
    +off_t find_superblock(int fd)
    +{
    +       off_t offset = 0;
    +       struct squashfs_super_block sBlk;
    +
    +       if(lseek(fd, 0, SEEK_SET) == -1) {
    +               ERROR("Lseek failed, error was %s\n", strerror(errno));
    +               return (off_t) -1;
    +       }
    +
    +       while(read(fd, &sBlk, sizeof(sBlk)) == sizeof(sBlk)) {
    +               if(sBlk.s_magic == SQUASHFS_MAGIC) {
    +                       TRACE("find_superblock: magic 0x%08X found at 0x%08X\n", sBlk.s_magic, (unsigned int) offset);
    +                       return offset;
    +               }
    +               else if(sBlk.s_magic == SQUASHFS_MAGIC_SWAP) {
    +                       TRACE("find_superblock: swapped magic 0x%08X found at 0x%08X\n", sBlk.s_magic, (unsigned int) offset);
    +                       has_swapped_endianess = TRUE;
    +                       return offset;
    +               }
    +               offset += 256;
    +               if(lseek(fd, offset, SEEK_SET) == -1) {
    +                       ERROR("Lseek failed, error was %s\n", strerror(errno));
    +                       return (off_t) -1;
    +               }
    +       }
    +
    +       return (off_t) -1;
    +}
    +
    +
    +unsigned int find_checksum(int fd)
    +{
    +       unsigned char buffer[8];
    +       off_t size;
    +
    +       size = lseek(fd, image_size - sizeof(buffer), SEEK_SET);
    +       if (size == -1) {
    +               ERROR("Lseek failed, error was %s\n", strerror(errno));
    +               return FALSE;
    +       }
    +       if (read(fd, buffer, sizeof(buffer)) == sizeof(buffer)) {
    +#ifdef SQUASHFS_TRACE
    +               unsigned char *b = buffer;
    +#endif
    +               TRACE("find_checksum: buffer content: %02x %02x %02x %02x %02x %02x %02x %02x\n", *b, *(b + 1), *(b + 2), *(b + 3), *(b + 4), *(b + 5), *(b + 6), *(b + 7));
    +               if (buffer[0] == 0x23 && buffer[1] == 0xDE && buffer[2] == 0x53 && buffer[3] == 0xC4) {
    +                       image_size = size;
    +                       return TRUE;
    +               }
    +       }
    +       else {
    +               ERROR("Reading the last 8 bytes failed, error was %s\n", strerror(errno));
    +               return FALSE;
    +       }
    +
    +       return FALSE;
    +}
    +
    +
    +unsigned int find_nmi_vector_location(int fd)
    +{
    +       off_t   current = 0x40;
    +
    +       TRACE("find_nmi_vector_location: image_size=%ld (0x%08lX)\n", (long) image_size, (long) image_size);
    +       while ((current + sizeof(nmi_vector_location)) < image_size) {
    +               if(lseek(fd, current, SEEK_SET) == -1) {
    +                       ERROR("Lseek failed, error was %s\n", strerror(errno));
    +                       return FALSE;
    +               }
    +               if (read(fd, &nmi_vector_location, sizeof(nmi_vector_location)) == sizeof(nmi_vector_location)) {
    +                       if (strncmp(nmi_vector_location.vector_id, "NMI Boot Vector\0", 16) == 0) {
    +                               nmi_vector_gap_start = current - 0x40;
    +                               if (has_swapped_endianess) { /* swap locally */
    +                                       unsigned int u;
    +                                       u = nmi_vector_location.vector_gap;
    +                                       nmi_vector_location.vector_gap = (( u & 0xFF000000 ) >> 24 ) |
    +                                                                        (( u & 0x00FF0000 ) >> 8 ) |
    +                                                                        (( u & 0x0000FF00 ) << 8 ) |
    +                                                                        (( u & 0x000000FF ) << 24 );
    +                                       u = nmi_vector_location.firmware_length;
    +                                       nmi_vector_location.firmware_length = (( u & 0xFF000000 ) >> 24 ) |
    +                                                                             (( u & 0x00FF0000 ) >> 8 ) |
    +                                                                             (( u & 0x0000FF00 ) << 8 ) |
    +                                                                             (( u & 0x000000FF ) << 24 );
    +                               }
    +                               TRACE("find_nmi_vector_location: at=0x%08X, size=0x%08X, firmware=0x%08X\n",(long)  current, (unsigned int) nmi_vector_location.vector_gap, (unsigned int) nmi_vector_location.firmware_length);
    +                               return TRUE;
    +                       }
    +               }
    +               else {
    +                       ERROR("Reading possible NMI vector location failed, error was %s\n", strerror(errno));
    +                       return FALSE;
    +               }
    +               current += 256;
    +       }
    +
    +       return FALSE;
    +}
    +
    +
     int read_fs_bytes(int fd, long long byte, int bytes, void *buff)
     {
    -       off_t off = byte;
    +       off_t off = byte + superblock_offset;
            int res, count;
    
    -       TRACE("read_bytes: reading from position 0x%llx, bytes %d\n", byte,
    +       TRACE("read_fs_bytes: reading from position 0x%llx, bytes %d\n", byte,
                    bytes);
    +
    +       if (has_nmi_vector_gap) {
    +               /*
    +               - if we're below and the last byte to read doesn't cross the line, there's
    +                 nothing to do (case A) - this case needs no handling and so it's the
    +                 default path, if none of the others match
    +               - if we're above or even at the "magic border", we simply add the gap size
    +                 to the requested offset (case B)
    +               - the only special case is a read starting before nmi_vector_gap_start and
    +                 running into the gap - here we'll split this single read into two
    +                 recursive calls to our own function, where the 1st access is shortened
    +                 to stop at the last byte before the gap and the 2nd will start over at
    +                 the gap offset and read the remaining bytes (it's case B for this
    +                 recursive call)
    +               */
    +               if (off >= nmi_vector_gap_start) {
    +                       /* case B */
    +                       off += nmi_vector_location.vector_gap;
    +               }
    +               else if ((off < nmi_vector_gap_start) && ((off + bytes) > nmi_vector_gap_start)) {
    +                       /* case C */
    +                       TRACE("read_fs_bytes: split read needed, abs=0x%08lX, rel=0x%08lX, count=0x%X, to=0x%08X\n", (long) off, (long) byte, bytes, buff);
    +                       if (read_fs_bytes(fd, byte, nmi_vector_gap_start - off, buff) == TRUE) {
    +#ifdef SQUASHFS_TRACE
    +                               unsigned char *b = buff + (nmi_vector_gap_start - off) - 4;
    +#endif
    +                               TRACE("read_fs_bytes: part 1 from=0x%08lX, size=0x%08lX", (long) byte, (long) (nmi_vector_gap_start - off));
    +                               TRACE("read_fs_bytes: buffer content around the gap: 0x%08lX %02x %02x %02x %02x %02x %02x %02x %02x\n", b, *b, *(b + 1), *(b + 2), *(b + 3), *(b + 4), *(b + 5), *(b + 6), *(b + 7));
    +                               res = read_fs_bytes(fd,
    +                                                   nmi_vector_gap_start - superblock_offset,
    +                                                   bytes - (nmi_vector_gap_start - off),
    +                                                   buff + (nmi_vector_gap_start - off)
    +                                                  );
    +                               TRACE("read_fs_bytes: part 2 from=0x%08lX, size=0x%08lX", (long) (nmi_vector_gap_start - superblock_offset), (long) (bytes - (nmi_vector_gap_start - off - 1)));
    +                               TRACE("read_fs_bytes: buffer content around the gap: 0x%08lX %02x %02x %02x %02x %02x %02x %02x %02x\n", b, *b, *(b + 1), *(b + 2), *(b + 3), *(b + 4), *(b + 5), *(b + 6), *(b + 7));
    +                               return res;
    +                       }
    +                       else return FALSE;
    +               }
    +       }
    
            if(lseek(fd, off, SEEK_SET) == -1) {
    -               ERROR("Lseek failed because %s\n", strerror(errno));
    +               ERROR("Lseek failed, error was %s\n", strerror(errno));
                    return FALSE;
            }
    
    @@ -2651,6 +2818,8 @@
                            use_regex = TRUE;
                    else if(strcmp(argv[i], "-exit-on-decomp-error") == 0)
                            exit_on_decompression_errors = TRUE;
    +               else if(strcmp(argv[i], "-scan") == 0 || strcmp(argv[i], "-k") == 0)
    +                       scan_for_superblock = TRUE;
                    else
                            goto options;
            }
    @@ -2715,6 +2884,10 @@
                            ERROR("\t\t\t\trather than use the default shell "
                                    "wildcard\n\t\t\t\texpansion (globbing)\n");
                            ERROR("\t-exit-on-decomp-error\texit on decompression errors\n");
    +                       ERROR("\t-scan or -k\t\ttreat filesystem as a combined image\n");
    +                       ERROR("\t\t\t\t(kernel+SquashFS) and scan it to locate the\n");
    +                       ERROR("\t\t\t\tsuperblock and its offset, enables NMI gap\n");
    +                       ERROR("\t\t\t\tcheck and processing and TI checksum detection\n");
                            ERROR("\nDecompressors available:\n");
                            display_compressors("", "");
                    }

  6. #6
    IPPF Achttausend-VIP Avatar von PeterPawn
    Registriert seit
    10.05.2006
    Ort
    Berlin
    Beiträge
    8.147
    So, noch einmal und letztmalig meinerseits der Versuch zu ermitteln, ob das erste Problem nach einem "make dirclean" noch auftritt oder nicht bzw. ob damit dann auch das Problem mit der "_endian.h" erledigt war ... irgendwie kann ich das dem bisher Geschriebenen nicht entnehmen.

    Ansonsten (ebenfalls) noch einmal der Hinweis, daß der Freetz-Trunk inzwischen bei den SquashFS-Tools dieselben Änderungen enthält (ggf. von @er13 etwas abgewandelt, aber die Funktionalitäten sollten übereinstimmen), wie sie auch im Fork vorhanden sind. Es gibt also keinen (offensichtlichen) Grund, den Fork zu verwenden.

    Nachtrag:
    Man kann zwar in #6 gar nicht sehen, welches Patch-File nun den Fehler verursacht, aber dem Inhalt der "rej"-Datei nach müßte es sich um "910-superblock_offset.patch" handeln ... das ist genau so ein Patch, der von @er13 in die Teil 610, 611 und 612 zerlegt wurde.

    Damit macht das nachträgliche Synchronisieren mit dem Freetz-Trunk bei mir natürlich immer wieder Probleme, weil Gene eben nicht den originalen Patch übernimmt und dann ändert (womit dann auch das nunmehr überflüssige 910-File entfernt würde beim Synchronisieren der Änderungen), sondern immer eigene Änderungen an den Dateien vornimmt.

    Damit greifen dann die normalen Mechanismen der Versionsverwaltung natürlich ins Leere, weil die nicht erkennen kann, daß aus einem Patch (910) drei andere (610-612) entstanden sind und der erste nun obsolet ist. Somit zieht jede in den Trunk auf diese (eher ungewöhnliche Art) übernommene Änderung auch für mich neue Arbeit nach sich, wenn ich den Fork und den Trunk nicht zu weit auseinanderlaufen lassen will.

    Bei diesem Teil der Änderungen habe ich vor 6 Monaten offensichtlich das Löschen des 910-Files versäumt, das habe ich jetzt (direkt im GitHub committed, daher ohne Signatur) nachgeholt. Damit sollte sich nach dem Synchronisieren der Kopie mit dem Fork auch dieses Problem in Wohlgefallen auflösen, weil dabei die 910-Datei gelöscht werden sollte.

  7. #7
    IPPF-Einsteiger
    Registriert seit
    17.02.2016
    Beiträge
    23
    Ja, jetzt läuft das make durch bis zum Ende.
    Viele Dank!
    Eberhard

Ähnliche Themen

  1. [Problem] Build Fehler mit FB 7490 und Freetz 13795
    Von PrinzVonBillAir im Forum Freetz
    Antworten: 3
    Letzter Beitrag: 25.06.2016, 17:48
  2. Antworten: 14
    Letzter Beitrag: 01.12.2013, 12:41
  3. [Gelöst] build/download-Fehler bei Asterisk - freetz-trunk ( 11233 )
    Von xsapling im Forum Freetz
    Antworten: 1
    Letzter Beitrag: 17.11.2013, 13:01
  4. Freetz Build-Fehler, PHP mit bundled GD-Lib
    Von Dr.Seltsam im Forum Freetz
    Antworten: 3
    Letzter Beitrag: 08.09.2010, 14:41
  5. Antworten: 7
    Letzter Beitrag: 16.06.2008, 09:03

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •