ckolivas / lrzip

Long Range Zip

Home Page:http://lrzip.kolivas.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

0.641 fails to build using macOS native tools

SMillerDev opened this issue · comments

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: Homebrew/homebrew-core#71422 for more log output

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.

I've done some more tinkering in Homebrew/homebrew-core#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 #211.

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.