ckolivas / lrzip

Long Range Zip
http://lrzip.kolivas.org
GNU General Public License v2.0
619 stars 76 forks source link

0.641 fails to build using macOS native tools #193

Open SMillerDev opened 3 years ago

SMillerDev commented 3 years ago

It looks like it is now making an empty archive (liblzmaasm) - which Apple's version of ar does not support doing.

nasm -I../ASM/x86/ -Dx64 -g -f elf64 -o 7zCrcOpt_asm.o /private/tmp/lrzip-20210307-2953-4qw1fu/lrzip-0.641/lzma/ASM/x86/7zCrcOpt_asm.asm
mkdir -p .libs
cp 7zCrcOpt_asm.o .libs/
  CCLD     liblzma.la
./7zCrcOpt_asm.lo: line 1: -e: command not found
Making all in ASM/x86
  CCLD     liblzmaasm.la
ar: no archive members specified
usage:  ar -d [-TLsv] archive file ...

See: https://github.com/Homebrew/homebrew-core/pull/71422 for more log output

chenrui333 commented 3 years ago

cc @ckolivas

pete4abw commented 3 years ago

The issue is that the echo -n command on a MacOS shell does not function as designed. You need to use /bin/echo You can just replace @echo -n with /bin/echo -n. A fix using configure.ac. @leleliu008 has a pull request #203 that replaces echo with a bunch of printf statements. I do not endorse that fix. lrzip and lrzip-next was designed for linux systems. MacOS is not quite the same. You will see other oddities like using substitutions which has been reported in lrzip-next.

alebcay commented 3 years ago

I've done some more tinkering in https://github.com/Homebrew/homebrew-core/pull/85360. #204 does fix the build, but not because it changes @echo to @printf. It works because it removes ASM/x86 from SUBDIRS.

The issue is in the ASM/x86 compilation unit. The ASM file(s) are not being built, so linking them into a liblzmaasm.la file without any archive members fails.

Interestingly, removing the compilation unit does not preclude optimized ASM features from being added:

nasm -I../ASM/x86/ -Dx64 -g -f elf64 -o 7zCrcOpt_asm.o /Volumes/Storage/Developer/lrzip/lrzip-0.641/lzma/ASM/x86/7zCrcOpt_asm.asm
+ nasm -I../ASM/x86/ -Dx64 -g -f elf64 -o 7zCrcOpt_asm.o /Volumes/Storage/Developer/lrzip/lrzip-0.641/lzma/ASM/x86/7zCrcOpt_asm.asm
mkdir -p .libs
+ mkdir -p .libs
cp 7zCrcOpt_asm.o .libs/
+ cp 7zCrcOpt_asm.o .libs/
+ echo -e '# 7zCrcOpt_asm.lo - a libtool object file \n# Generated by libtool -- hack to allow asm linking \n# Peter Hyman \npic_object='\''.libs/7zCrcOpt_asm.o'\'' \nnon_pic_object='\''7zCrcOpt_asm.o'\'''
+ echo '  CCLD    ' liblzma.la
  CCLD     liblzma.la
+ sh -x ../../libtool --silent --tag=CC --mode=link gcc -D_REENTRANT -I../.. -I../.. -g -O2 -pthread -o liblzma.la 7zCrcT8.lo LzFind.lo LzFindMt.lo LzmaDec.lo LzmaEnc.lo LzmaLib.lo Alloc.lo Threads.lo 7zCrcOpt_asm.lo -llz4 -llzo2 -lbz2 -lz -lm -lpthread

Perhaps of concern on macOS is that the assembler is creating an elf64 object instead of macho64, but the compilation and brief smoke test seem to work either way. Addressed this in https://github.com/ckolivas/lrzip/pull/211.

pete4abw commented 3 years ago

ASM is unnecessary just for CRC. I should not have bothered putting it back in. In the LZMA SDK 18.00+ there is an ASM Decompressor which is blazingly fast. There I did take the time to convert the code to NASM.. In SDK 21.03beta there is also an LZFind assembler module which does match finding much faster too. X86_64 only. Some additional work on lrzip-next and MAC has been done on my site. This includes using MD5 hashing. But it's not perfect and never will be.