On 2022/09/18 15:49, Josh Grosse wrote:
> On Sun, Sep 18, 2022 at 12:47:28AM -0400, George Koehler wrote:
> > On Fri, 16 Sep 2022 21:54:54 -0400
> > Josh Grosse <j...@jggimi.net> wrote:
> >
> > > Attached is a "v3" tarball with the above changes, producing a single
> > > `7zz`
> > > executable binary. There is no long any conflict with p7zip. I've tested
> > > this build on amd64. George may want to retest on powerpc64 to see if his
> > > patch to
> > > C/7zCrcOpt.c can be removed.
> >
> > Yes, please $ rm patches/patch-C_7zCrcOpt_c
> >
> > I can now build 7zz without patch-C_7zCrcOpt_c on both macppc (which
> > is 32-bit powerpc) and powerpc64. Also, we can remove 7zCrcOpt.c
> > from FIX_CRLF_FILES.
>
> Both are complete in the attached "v4" tarball.
>
> > 7zz does more formats than 7za, see "7zz i". I can extract my old
> > .rar file with 7zz. Other distros (Alpine, Debian, FreeBSD) are also
> > building 7zz and not 7za. (Alpine and FreeBSD also symlink 7z to 7zz;
> > Alpine and Debian also disable the .rar code.)
>
> It should be easy enough to disable with the knobs provided, either
> DISABLE_RAR=1
> or DISABLE_RAR_COMPRESS=1. But there is the dependency for the p7zip unrar
> plugin in mail/amavisd-new, and I am looking forward to the day when p7zip
> will be removed.
The issue with the unrar code is that it changes the produced binary to
a non-free license. That's why it is packaged separately in p7zip.
(roughly "must not use to create a rar compatible compressor")
> > Another problem: the port sets COMPILER = base-clang ports-gcc, but
> > I believe that gcc can't build this port as is. I don't have a real
> > gcc arch (sparc64). I try forcing "make COMPILER=ports-gcc" on a
> > clang arch. (I know that COMPILER=ports-gcc on a clang arch can go
> > wrong when mixing C++ code from clang and gcc.)
> >
> > 1st problem, cmpl_clang.mak is running clang, not gcc. I try to
> > use cmpl_gcc.mak instead, this way,
> >
> > MAKE_FILE_base-clang = ../../cmpl_clang.mak
> > MAKE_FILE_ports-gcc = ../../cmpl_gcc.mak
> > MAKE_FILE = ${MAKE_FILE_${CHOSEN_COMPILER}}
>
> I like that solution.
>
> > 2nd problem, gcc immediately fails with,
> > egcc: error: unrecognized command line option '-Waddress-of-packed-member'
> >
> > I have not tried to remove the option.
>
> I did, and on amd64 I get an assembly error compiling C/LzFind.c. Log
> fragment follows:
>
> ===> Building for 7zip-22.01
> gcc -O2 -c -Wall -Wextra -Waddress -Waggressive-loop-optimizations
> -Wattributes -Wbool-compare -Wbool-operation -Wcast-align -Wcast-align=strict
> -Wcomment -Wdangling-else -Wdiv-by-zero -Wduplicated-branches
> -Wduplicated-cond -Wformat-contains-nul -Wimplicit-fallthrough=5 -Winit-self
> -Wint-in-bool-context -Wint-to-pointer-cast -Wunused -Wunused-macros
> -Wconversion -DNDEBUG -D_REENTRANT -D_FILE_OFFSET_BITS=64
> -D_LARGEFILE_SOURCE -fPIC -o b/g/LzFind.o ../../../../C/LzFind.c
Still not setting CC/CFLAGS otherwise that would have egcc and -O2 -pipe.
> /tmp//ccGUWuj4.s: Assembler messages:
That's a problem in ports/lang/gcc, it needs to use a current version of
gas not the 15 year old one in base. (IIRC it needs some other ports fixing
too).
> /tmp//ccGUWuj4.s:479: Error: no such instruction: `vpbroadcastd
> -4(%rsp),%ymm0'
...but unless I'm mistaken that is an AVX512 instruction which it
shouldn't be using at all because there's no command line flag allowing
it to use them.
You really need a test on a base-gcc arch for this bit.
