lrzip
lrzip copied to clipboard
0.641 fails to build using macOS native tools
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
cc @ckolivas
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 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.
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.