I've done something wrong

What version of debian/ubuntu can you build this on?

cc -g -O2  -I. -I./LZMA/lzma465/C -I./LZMA/lzmalt -I./LZMA/lzmadaptive/C/7zip/Compress/LZMA_Lib -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_GNU_SOURCE -DCOMP_DEFAULT=\"gzip\" -Wall -Werror  -DGZIP_SUPPORT -DLZMA_SUPPORT -DXZ_SUPPORT -DLZO_SUPPORT -DXATTR_SUPPORT -DXATTR_DEFAULT   -c -o xz_wrapper.o xz_wrapper.c
In file included from xz_wrapper.c:31:0:
xz_wrapper.h:50:2: error: unknown type name ‘lzma_vli’
  lzma_vli id;
  ^
xz_wrapper.h:56:2: error: unknown type name ‘lzma_filter’
  lzma_filter filter[3];
  ^
xz_wrapper.h:64:2: error: unknown type name ‘lzma_options_lzma’
  lzma_options_lzma opt;
  ^
xz_wrapper.c:35:11: error: ‘LZMA_FILTER_X86’ undeclared here (not in a function)
  { "x86", LZMA_FILTER_X86, 0 },
           ^
xz_wrapper.c:36:15: error: ‘LZMA_FILTER_POWERPC’ undeclared here (not in a function)
  { "powerpc", LZMA_FILTER_POWERPC, 0 },
               ^
xz_wrapper.c:37:12: error: ‘LZMA_FILTER_IA64’ undeclared here (not in a function)
  { "ia64", LZMA_FILTER_IA64, 0 },
            ^
xz_wrapper.c:38:11: error: ‘LZMA_FILTER_ARM’ undeclared here (not in a function)
  { "arm", LZMA_FILTER_ARM, 0 },
           ^
xz_wrapper.c:39:16: error: ‘LZMA_FILTER_ARMTHUMB’ undeclared here (not in a function)
  { "armthumb", LZMA_FILTER_ARMTHUMB, 0 },

Ok, so further testing, doesn't compile on ubuntu, but does on debian:jessie, all good

same on windows.. cygwin... normal squashfs compiles... with your patches it doesn't...

errors starts at unknown type name ‘lzma_vli’...

Please provide more information, as it builds fine here (Ubuntu 14.04 32 bit, gcc v4.8.4):

What command(s) are you running to patch/build?
What version gcc are you using?
What OS/version are you compiling on?

I also has this question in ubuntu 14.04 64bit, gcc (Ubuntu 4.8.4-2ubuntu1~14.04) 4.8.4

@freman

The errors that @freman posted are specifically from xz_wrapper.c, which the sasquatch patches don't touch. However, by default, xz_wrapper.c is never used by squashfs-tools, since it is commented out in the Makefile. The sasqatch patches do enable XZ support in the Makefile.

The specific errors seem to suggest that there are some things from the lzma library that xz_wrapper.c expects, but are not defined. This sounds like an issue with your installed lzma library, but to make sure, try downloading the unpatched squashfs-tools, edit the Makefile to comment out the XZ_SUPPORT = 1 line, and try to build:

  #                                                           |  #                                                          
  # XZ Utils liblzma (http://tukaani.org/xz/) is supported    |  # XZ Utils liblzma (http://tukaani.org/xz/) is supported   
  #                                                           |  #                                                          
  # To build using XZ Utils liblzma - install the library and |  # To build using XZ Utils liblzma - install the library and
  # the XZ_SUPPORT line below.                                |  # the XZ_SUPPORT line below.                               
  #                                                           |  #                                                          
  XZ_SUPPORT = 1

If you get the same errors, then the problem is with your lzma library, not with the patches. If it builds fine, then it's probably an issue with the Makefile patches.

@devttys0

So I had the same issue as the op:

OS: Linux 4.8.0-27-generic FATAL ERROR:Line too long when reading extract file "***.bin", larger than 16384 bytes #29-Ubuntu SMP Thu Oct 20 21:03:13 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
GCC: gcc (Ubuntu 6.2.0-5ubuntu12) 6.2.0 20161005

Here's what I tried:

I follow the instructions by @devttys0. Took me a while to catch on that no matter how many times I modified the Makefile, it was constantly overwritten by the build.sh as squashfs4.3.tar.gz gets downloaded and uncompressed by running the script. So I commented the following lines in the build.sh script and forced the patches :

    # Remove any previous squashfs4.3 directory to ensure a clean patch/build
    #rm -rf squashfs4.3

    # Extract squashfs4.3.tar.gz
    #tar -zxvf squashfs4.3.tar.gz

    # Patch, build, and install the source
    cd squashfs4.3
    patch -f -p0 < ../patches/patch0.txt

While this solved the first issue, it created another one:

cc -g -O2  -I. -I./LZMA/lzma465/C -I./LZMA/lzmalt -I./LZMA/lzmadaptive/C/7zip/Compress/LZMA_Lib -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_GNU_SOURCE -DCOMP_DEFAULT=\"gzip\" -Wall -Werror  -DGZIP_SUPPORT -DLZMA_SUPPORT -DXZ_SUPPORT -DLZO_SUPPORT -DXATTR_SUPPORT -DXATTR_DEFAULT   -c -o unsquashfs.o unsquashfs.c
In file included from unsquashfs.h:58:0,
                 from unsquashfs.c:26:
squashfs_fs.h:525:8: error: redefinition of ‘struct lzma_override_property’
 struct lzma_override_property
        ^~~~~~~~~~~~~~~~~~~~~~
squashfs_fs.h:508:8: note: originally defined here
 struct lzma_override_property
        ^~~~~~~~~~~~~~~~~~~~~~
squashfs_fs.h:530:8: error: redefinition of ‘struct override_table’
 struct override_table
        ^~~~~~~~~~~~~~
squashfs_fs.h:513:8: note: originally defined here
 struct override_table
        ^~~~~~~~~~~~~~
unsquashfs.c: In function ‘check_compression’:
unsquashfs.c:1783:6: error: expected expression before ‘/’ token
     */
      ^
<builtin>: recipe for target 'unsquashfs.o' failed
make: *** [unsquashfs.o] Error 1

From there, I had to commented the redefinitions in squashfs_fs.h and got rid of the lonely end-comment tag in unsquashfs.c.

Then you get the following:

In file included from unsquashfs.c:28:0:
unsquashfs.c: In function ‘check_compression’:
unsquashfs.c:1787:45: error: ‘sBlk_3’ undeclared (first use in this function)
         SQUASHFS_SWAP_SUPER_BLOCK_3(&sblk, &sBlk_3);

Commented out the lines from 1786 to 1789 as I cannot find where &sBlk_3 in the entire file.

    if(swap)
    {
        //squashfs_super_block_3 sblk;
        //SQUASHFS_SWAP_SUPER_BLOCK_3(&sblk, &sBlk_3);
        //memcpy(&sBlk_3, &sblk, sizeof(squashfs_super_block_3));
    }

compressor.c:113:5: error: redefinition of ‘lookup_compressor_index’
 int lookup_compressor_index(char *name)

At this point, I gave up for now. No issue compiling squashfs without the patches.

I was redirected to this issue when looking for the similar issue on Cygwin instead:

gcc version 6.4.0 (GCC)
COLLECT_GCC_OPTIONS='-g' '-O2' '-v' '-Wno-error=unused-variable' '-D' 'linux' '-D' 'FNM_EXTMATCH=(1<<5)' '-D' 'sigtimedwait(a,b,c)=sigwaitinfo(a,b)' '-D' 'GZIP_SUPPORT' '-D' 'LZMA_SUPPORT' '-D' 'XZ_SUPPORT' '-I' '.' '-I' './LZMA/lzma465/C' '-I' './LZMA/lzmalt' '-I' './LZMA/lzmadaptive/C/7zip/Compress/LZMA_Lib' '-D' '_FILE_OFFSET_BITS=64' '-D' '_LARGEFILE_SOURCE' '-D' '_GNU_SOURCE' '-D' 'COMP_DEFAULT="gzip"' '-Wall' '-Werror' '-D' 'GZIP_SUPPORT' '-D' 'LZMA_SUPPORT' '-D' 'XZ_SUPPORT' '-D' 'LZO_SUPPORT' '-D' 'XATTR_SUPPORT' '-D' 'XATTR_DEFAULT' '-c' '-o' 'xz_wrapper.o' '-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-pc-cygwin/6.4.0/cc1.exe -quiet -v -I . -I ./LZMA/lzma465/C -I ./LZMA/lzmalt -I ./LZMA/lzmadaptive/C/7zip/Compress/LZMA_Lib -Dunix -idirafter /usr/lib/gcc/x86_64-pc-cygwin/6.4.0/../../../../lib/../include/w32api -idirafter /usr/lib/gcc/x86_64-pc-cygwin/6.4.0/../../../../x86_64-pc-cygwin/lib/../lib/../../include/w32api -D linux -D FNM_EXTMATCH=(1<<5) -D sigtimedwait(a,b,c)=sigwaitinfo(a,b) -D GZIP_SUPPORT -D LZMA_SUPPORT -D XZ_SUPPORT -D _FILE_OFFSET_BITS=64 -D _LARGEFILE_SOURCE -D _GNU_SOURCE -D COMP_DEFAULT="gzip" -D GZIP_SUPPORT -D LZMA_SUPPORT -D XZ_SUPPORT -D LZO_SUPPORT -D XATTR_SUPPORT -D XATTR_DEFAULT xz_wrapper.c -quiet -dumpbase xz_wrapper.c -mtune=generic -march=x86-64 -auxbase-strip xz_wrapper.o -g -O2 -Wno-error=unused-variable -Wall -Werror -version -o /tmp/ccnpSBxp.s
GNU C11 (GCC) version 6.4.0 (x86_64-pc-cygwin)
compiled by GNU C version 6.4.0, GMP version 6.1.2, MPFR version 3.1.6-p1, MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-pc-cygwin/6.4.0/include-fixed"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-pc-cygwin/6.4.0/../../../../x86_64-pc-cygwin/include"
ignoring duplicate directory "/usr/lib/gcc/x86_64-pc-cygwin/6.4.0/../../../../x86_64-pc-cygwin/lib/../lib/../../include/w32api"
#include "..." search starts here:
#include <...> search starts here:
.
./LZMA/lzma465/C
./LZMA/lzmalt
./LZMA/lzmadaptive/C/7zip/Compress/LZMA_Lib
/usr/lib/gcc/x86_64-pc-cygwin/6.4.0/include
/usr/include
/usr/lib/gcc/x86_64-pc-cygwin/6.4.0/../../../../lib/../include/w32api
End of search list.
GNU C11 (GCC) version 6.4.0 (x86_64-pc-cygwin)
compiled by GNU C version 6.4.0, GMP version 6.1.2, MPFR version 3.1.6-p1, MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 2d3d11644c64278db33cf4cc4625e9ee
In file included from xz_wrapper.c:31:0:
xz_wrapper.h:51:2: error: unknown type name ‘lzma_vli’
lzma_vli id;
^~~~~~~~
xz_wrapper.h:57:2: error: unknown type name ‘lzma_filter’
lzma_filter filter[3];
^~~~~~~~~~~
xz_wrapper.h:65:2: error: unknown type name ‘lzma_options_lzma’
lzma_options_lzma opt;
^~~~~~~~~~~~~~~~~
xz_wrapper.c:35:11: error: ‘LZMA_FILTER_X86’ undeclared here (not in a function)
{ "x86", LZMA_FILTER_X86, 0 },

It appears that lzma.h header file cannot be located properly because of the same lzma.h header file defined in ./LZMA directory, realized that after some trial and error steps:

$ find . -iname "lzma.h"
./LZMA/lzmadaptive/C/7zip/Compress/LZMA/LZMA.h
./LZMA/lzmalt/LZMA.h

I solved this by renaming the collided LZMA.h to LZMA2.h and renamed the source files that reference to this header file:

$ grep -nR --include=.c --include=.h "LZMA.h" .
./LZMA/lzmadaptive/C/7zip/Compress/LZMA/LZMA.h:1:// LZMA.h
./LZMA/lzmadaptive/C/7zip/Compress/LZMA/LZMADecoder.h:12:#include "LZMA.h"
./LZMA/lzmadaptive/C/7zip/Compress/LZMA/LZMAEncoder.h:12:#include "LZMA.h"
./LZMA/lzmalt/LZMADecoder.h:5:#include "LZMA.h"

Recompile and it works like a charm:

$ make EXTRA_CFLAGS="-Wno-error=unused-variable -Dlinux -DFNM_EXTMATCH='(1<<5)' -D'sigtimedwait(a,b,c)=sigwaitinfo(a,b)' -DGZIP_SUPPORT -DLZMA_SUPPORT -DXZ_SUPPORT"

@x9090

@x9090
It's not clear what you replaced.
What exactly did you rename?
What about the C files?

I get:

LZMA/lzma465/C/LzmaUtil/Lzma86Enc.h:14:.lzma86 header adds one additional byte to standard .lzma header.
LZMA/lzmadaptive/C/7zip/Compress/LZMA/LZMA.h:1:// LZMA.h
LZMA/lzmadaptive/C/7zip/Compress/LZMA/LZMA.h:3:#ifndef __LZMA_H
LZMA/lzmadaptive/C/7zip/Compress/LZMA/LZMA.h:4:#define __LZMA_H
LZMA/lzmadaptive/C/7zip/Compress/LZMA/LZMADecoder.h:12:#include "LZMA.h"
LZMA/lzmadaptive/C/7zip/Compress/LZMA/LZMAEncoder.h:12:#include "LZMA.h"
LZMA/lzmalt/LZMA.h:3:#ifndef __LZMA_H
LZMA/lzmalt/LZMA.h:4:#define __LZMA_H
LZMA/lzmalt/LZMADecoder.h:5:#include "LZMA.h"
...
lzma_xz_wrapper.c:26:#include <lzma.h>
xz_wrapper.c:28:#include <lzma.h>

@x9090

Following @x9090 hints, I had to rename all the "LZMA.h" files differently.

From ./sasquatch/squashfs4.3/squashfs-tools I did:

cd LZMA/lzmadaptive/C/7zip/Compress/LZMA/
mv LZMA.h LZMA2.h

cd LZMA/lzmalt/
mv LZMA.h LZMA3.h

# check renamings with:
#find . -name "LZMA[23].h"
./LZMA/lzmadaptive/C/7zip/Compress/LZMA/LZMA2.h
./LZMA/lzmalt/LZMA3.h

# Edit the files
nano LZMA/lzmadaptive/C/7zip/Compress/LZMA/LZMADecoder.h
nano LZMA/lzmadaptive/C/7zip/Compress/LZMA/LZMAEncoder.h
nano LZMA/lzmalt/LZMADecoder.h

# Check changes
# grep -n --color=always -H -R -i -E "LZMA.{0,1}\.h" --include="*.c" --include="*.h"
LZMA/lzmadaptive/C/7zip/Compress/LZMA/LZMA2.h:1:// LZMA.h
LZMA/lzmadaptive/C/7zip/Compress/LZMA/LZMADecoder.h:12:#include "LZMA2.h"
LZMA/lzmadaptive/C/7zip/Compress/LZMA/LZMAEncoder.h:12:#include "LZMA2.h"
LZMA/lzmalt/LZMADecoder.h:5:#include "LZMA3.h"
lzma_xz_wrapper.c:26:#include <lzma.h>
xz_wrapper.c:28:#include <lzma.h>

#make clean
#make
#make install

ALL GOOD!! 🥇

In docker for debian jessie and ubuntu latest build.sh doesnt work

chore(deps): improve LZMA dependencies resolution during pre-processing.

Navigation Menu

Repository navigation

I've done something wrong #6

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

I've done something wrong #6

Description

Activity

swynter-ladbrokes commented on Oct 6, 2015

Zibri commented on Aug 23, 2016

devttys0 commented on Aug 25, 2016

0xling commented on Sep 26, 2016

devttys0 commented on Sep 26, 2016

InfectedPacket commented on Nov 15, 2016

x9090 commented on Aug 7, 2018

E3V3A commented on Oct 17, 2018

E3V3A commented on Oct 17, 2018

docfate111 commented on May 6, 2021

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions