Maneage - Bugs: bug #60256, Crash when building Zip/Unzip...
You are not allowed to post comments on this tracker with your current authentication level.
bug #60256: Crash when building Zip/Unzip after macOS upgrade
Submitter: | Raul Infante-Sainz <infantesainz> | ||
Submitted: | Thu 18 Mar 2021 11:07:26 PM UTC | ||
Category: | Software | Severity: | 3 - Normal |
Item Group: | Crash | Status: | None |
Privacy: | Public | Assigned to: | None |
Open/Closed: | Open |
Fri 16 Jul 2021 11:00:58 PM UTC, comment #2: |
Mohammad Akhlaghi <makhlaghi>![]() |
Fri 16 Jul 2021 09:36:52 PM UTC, comment #1: This looks like a bug in the zip source package configure file.
I think the "OF" macro is irrelevant in this particular case - it's a macro that in this case does nothing, since tailor.h is included earlier.
According to a man page dated 2017-03-13 for memset, it appears that under POSIX.1-2001, POSIX.1-2008, C89, C99, SVr4, 4.3BSD, the declaration of memset should be:
So the zip definition ifdef ZMEM does appear to be in contradiction to the POSIX standards. It appears to be enabled by the compile line
(though strictly speaking this is for crc32.c; my guess is that we see the bug with zip.c instead of crc32.c due to parallel compiling).
It appears that these lines in unix/configure (in zip-3.0) fail to detect a system-level memset and so they enable the -DZMEM compile flag:
It looks like this configure section is buggy: the include line
is absent from the configure script.
Fixing this upstream at http://infozip.sourceforge.net/Zip.html#Release does not look realistic since the latest release is 7 July 2008, although in principle we should try.
The equivalent bug exists in unzip-6.0 , which does not appear to be maintained.
With our current definition of gbuild in build-rules.mk, there are no options for modifying the configure file after unpacking the tarball and before configuring (nor for modifying the Makefile before running make), and it appears that CFLAGS="-DBIG_MEM -DMMAP" is ignored (the configure script looks like a handwritten script, not the usual autotools script made with autoconf), so adding another flag such as -UZMEM would not work as a workaround.
Options for zip + unzip that I see are:
(1a) copy/paste the gbuild instructions into the zip + unzip rules in basic.mk and insert an sed command to replace the existing creation of conftest.c for ZMEM in configure by
or
(1b,c) modify gbuild to be a bit more flexible so that we can do essentially the same as (1), but without the big copy/paste of the rest of the unpack/configure/compile/install cycle, either (1b) with an sed command or (1c) with a patch file;
or
(2) provide our own fork of zip-3.0 and unzip-6.0 on a git repository with this change (and later mirrored on akhlaghi.org and zenodo, but best to also have an upstream git repository).
Why does gcc compile zip and unzip without a problem?
So in terms of POSIX standards, the "problem" in this case, if I've understood it correctly, is that gcc is "too reasonable", and Darwin/xnu + Xcode is too strict, but is formally correct.
What option would be best - (1a), (1b), (1c) or (2) or (other)?
|
Boud Roukema <boud>![]() |
Thu 18 Mar 2021 11:07:26 PM UTC, original submission:
When trying to build Maneage from scratch after upgrading macOS to Big Sur 11.2.3, it crashes at the installation of Zip/Unzip. This is something related with the 'OF' element just after 'memset', 'memcpy' or 'memcmp'. Here the relevant lines of the output:
|
Raul Infante-Sainz <infantesainz>![]() |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Thanks for the great review of the problem Boud. It was very clear and full of good points (to learn from).
We actually have a hack for this in some packages, like CFITSIO (where we unpack the main source, fix the configure script, package it again and give the modified package to 'gbuild'.
But I agree, that having this done directly within 'gbuild' as an extra option would be very useful/clean. Generally, both 'gbuild' and 'cbuild' should be changed into scripts to allow easier editing. I just defined task #16017 for this.
I just had a look at the build instructions of Zip/Unzip in Homebrew, I see that it builds on Big Sur.
When I look into the Homebrew instructions for Zip, I see that they also say that "Upstream is unmaintained", so they use Debian's tarball, and apply 10 patches! The patches are available on Debian. Probably its easier if we apply those patches, build a tarball from the patched source, and put that tarball on our own copy of software Zenodo.
But in any case, a fast look at the names of the patches, doesn't hint at them being related to 'memset' unfortunately.
It is very sad to see that no-one has taken the role of maintaining such a commonly used package! The same thing happened to Bzip2 when we started building software in Maneage (its core developer stopped developing it and it was only available from Debian). However, after looking again while writing this, I was happy to see Bzip2 development is now active again.