lrzip icon indicating copy to clipboard operation
lrzip copied to clipboard

0.641 fails to build using macOS native tools

Open SMillerDev opened this issue 3 years ago • 4 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: https://github.com/Homebrew/homebrew-core/pull/71422 for more log output

SMillerDev avatar Mar 17 '21 19:03 SMillerDev

cc @ckolivas

chenrui333 avatar Aug 21 '21 18:08 chenrui333

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.

pete4abw avatar Aug 21 '21 18:08 pete4abw

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.

alebcay avatar Sep 17 '21 15:09 alebcay

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.

pete4abw avatar Sep 17 '21 18:09 pete4abw