bugManeage - 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: 

Thanks for the great review of the problem Boud. It was very clear and full of good points (to learn from).

> 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

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.

> ... after upgrading macOS to Big Sur 11.2.3, it crashes at the installation of Zip/Unzip

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.

Mohammad Akhlaghi <makhlaghi>
Group administrator
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:

void *memset(void *s, int c, size_t n);

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

cc ... -DZMEM ...

(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:

   521  echo Check for memset
   522  echo "int main(){ char k; memset(&k,0,0); return 0; }" > conftest.c
   523  $CC -o conftest conftest.c >/dev/null 2>/dev/null
   524  [ $? -ne 0 ] && CFLAGS="${CFLAGS} -DZMEM"
   525


It looks like this configure section is buggy: the include line

#include <string.h>

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

printf "#include <string.h>\nint main(){ char k; memset(&k,0,0); return 0; }\n" > conftest.c


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?
My guess: gcc works because it considers the conftest.c lack of an include statement to be only a warning, not an error, and returns 0 in the configure test.

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>
Group Member
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:


cc -c -I. -Ibzip2 -DUNIX -O3 -DLARGE_FILE_SUPPORT -DUNICODE_SUPPORT
-DUTF8_MAYBE_NATIVE -DNO_FCHMOD -DNO_FCHOWN -DNO_LCHOWN -DNO_NL_LANGINFO
-DNO_LCHMOD -DZMEM -DNO_DIR -DHAVE_DIRENT_H -DHAVE_TERMIOS_H -D_MBCS
crc32.c
In file included from zip.c:16:
./zip.h:726:10: error: conflicting types for 'memset'
    char *memset OF((char *, int, unsigned int));
          ^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/string.h:74:7:
note: previous declaration is here
void    *memset(void *__b, int __c, size_t __len);
          ^
In file included from zip.c:16:
./zip.h:727:10: error: conflicting types for 'memcpy'
    char *memcpy OF((char *, char *, unsigned int));
          ^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/string.h:72:7:
note: previous declaration is here
void    *memcpy(void *__dst, const void *__src, size_t __n);
          ^
In file included from zip.c:16:
./zip.h:728:8: error: conflicting types for 'memcmp'
    int memcmp OF((char *, char *, unsigned int));
        ^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/string.h:71:6:
note: previous declaration is here
int      memcmp(const void *__s1, const void *__s2, size_t __n);
          ^


Raul Infante-Sainz <infantesainz>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by makhlaghi (Posted a comment)
  • -email is unavailable- added by boud (Posted a comment)
  • -email is unavailable- added by infantesainz (Submitted the item)
  •  

    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.

     

    No changes have been made to this item

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code