Olivier Bertrand added a comment - 2017-01-17 10:00 I don't know what compiler you are using because these files (ioapi.c, zip.c and unzip.c) are successfully compiled on all platforms used by buildbot. They are not written by me but imported from the MiniZip project (see the copyright in the file headers) and you should contact the authors. Meanwhile, if you are not interested by zipped tables, you can compile with CONNECT_WITH_ZIP "Compile CONNECT storage engine with ZIP support" OFF I don't know if this can be specified when compiling, if not you have to edit the CMakeLists.txt of the CONNECT plugin to do so.

Brian Evans added a comment - 2017-01-18 02:35 @bertransop I was using GCC 5.4.0 as the emerge-info.txt file shows (which is a summary of all the build tools) Yes, I've disabled CONNECT_WITH_ZIP for now in Gentoo's 10.0.29. I hope to find a solution so that Gentoo users can benefit from such easy functionality

Brian Evans added a comment - 2017-01-18 03:38 I've found if I comment out the supplied minizip files and use the system copy from zlib, everything compiles just fine. I'll work on a patch for review and comment

Olivier Bertrand added a comment - 2017-01-18 11:06 I compared the minizip files I had included in CONNECT source with the latest ones in the ZLIB source. There is no difference in the *.h files and only typo changes in the *.c files (spelling errors corrected in comments and in a variable name.) Curiously enough, the Windows file compare shows for ioapi.c: E:\MariaDB-10.1\Connect\storage\connect>fc /W /N ioapi.c E:\Zlib\zlib-1.2.11\contrib\minizip\*.* Comparaison des fichiers ioapi.c et E:\ZLIB\ZLIB-1.2.11\CONTRIB\MINIZIP\ioapi.c ***** ioapi.c 101: mode_fopen = "rb"; 102: else ***** E:\ZLIB\ZLIB-1.2.11\CONTRIB\MINIZIP\ioapi.c 100: mode_fopen = "rb"; 101: else ***** But no differences are visible using an editor. Anyway, none of them explain why ones compile and the other ones do not. It would be interesting to see what happens on your site.

Brian Evans added a comment - 2017-01-19 01:21 Interestingly enough, they are not the same on my machine. The only thing that Gentoo does is call autoreconf in the minizip directory when building zlib. No 3rd-party patches --- /var/tmp/portage/dev-db/mariadb-10.0.29/work/mysql/storage/connect/ioapi.h 2017-01-11 20:45:20.000000000 -0500 +++ /usr/include/minizip/ioapi.h 2017-01-16 22:23:48.000000000 -0500 @@ -132,14 +132,14 @@ -typedef voidpf (ZCALLBACK *open_file_func) OF((voidpf opaque, const char* filename, int mode)); -typedef uLong (ZCALLBACK *read_file_func) OF((voidpf opaque, voidpf stream, void* buf, uLong size)); -typedef uLong (ZCALLBACK *write_file_func) OF((voidpf opaque, voidpf stream, const void* buf, uLong size)); -typedef int (ZCALLBACK *close_file_func) OF((voidpf opaque, voidpf stream)); -typedef int (ZCALLBACK *testerror_file_func) OF((voidpf opaque, voidpf stream)); +typedef voidpf (ZCALLBACK *open_file_func) _Z_OF((voidpf opaque, const char* filename, int mode)); +typedef uLong (ZCALLBACK *read_file_func) _Z_OF((voidpf opaque, voidpf stream, void* buf, uLong size)); +typedef uLong (ZCALLBACK *write_file_func) _Z_OF((voidpf opaque, voidpf stream, const void* buf, uLong size)); +typedef int (ZCALLBACK *close_file_func) _Z_OF((voidpf opaque, voidpf stream)); +typedef int (ZCALLBACK *testerror_file_func) _Z_OF((voidpf opaque, voidpf stream)); -typedef long (ZCALLBACK *tell_file_func) OF((voidpf opaque, voidpf stream)); -typedef long (ZCALLBACK *seek_file_func) OF((voidpf opaque, voidpf stream, uLong offset, int origin)); +typedef long (ZCALLBACK *tell_file_func) _Z_OF((voidpf opaque, voidpf stream)); +typedef long (ZCALLBACK *seek_file_func) _Z_OF((voidpf opaque, voidpf stream, uLong offset, int origin)); /* here is the "old" 32 bits structure structure */ @@ -155,9 +155,9 @@ voidpf opaque; } zlib_filefunc_def; -typedef ZPOS64_T (ZCALLBACK *tell64_file_func) OF((voidpf opaque, voidpf stream)); -typedef long (ZCALLBACK *seek64_file_func) OF((voidpf opaque, voidpf stream, ZPOS64_T offset, int origin)); -typedef voidpf (ZCALLBACK *open64_file_func) OF((voidpf opaque, const void* filename, int mode)); +typedef ZPOS64_T (ZCALLBACK *tell64_file_func) _Z_OF((voidpf opaque, voidpf stream)); +typedef long (ZCALLBACK *seek64_file_func) _Z_OF((voidpf opaque, voidpf stream, ZPOS64_T offset, int origin)); +typedef voidpf (ZCALLBACK *open64_file_func) _Z_OF((voidpf opaque, const void* filename, int mode)); typedef struct zlib_filefunc64_def_s { @@ -171,8 +171,8 @@ voidpf opaque; } zlib_filefunc64_def; -void fill_fopen64_filefunc OF((zlib_filefunc64_def* pzlib_filefunc_def)); -void fill_fopen_filefunc OF((zlib_filefunc_def* pzlib_filefunc_def)); +void fill_fopen64_filefunc _Z_OF((zlib_filefunc64_def* pzlib_filefunc_def)); +void fill_fopen_filefunc _Z_OF((zlib_filefunc_def* pzlib_filefunc_def)); /* now internal definition, only for zip.c and unzip.h */ typedef struct zlib_filefunc64_32_def_s @@ -191,9 +191,9 @@ #define ZCLOSE64(filefunc,filestream) ((*((filefunc).zfile_func64.zclose_file)) ((filefunc).zfile_func64.opaque,filestream)) #define ZERROR64(filefunc,filestream) ((*((filefunc).zfile_func64.zerror_file)) ((filefunc).zfile_func64.opaque,filestream)) -voidpf call_zopen64 OF((const zlib_filefunc64_32_def* pfilefunc,const void*filename,int mode)); -long call_zseek64 OF((const zlib_filefunc64_32_def* pfilefunc,voidpf filestream, ZPOS64_T offset, int origin)); -ZPOS64_T call_ztell64 OF((const zlib_filefunc64_32_def* pfilefunc,voidpf filestream)); +voidpf call_zopen64 _Z_OF((const zlib_filefunc64_32_def* pfilefunc,const void*filename,int mode)); +long call_zseek64 _Z_OF((const zlib_filefunc64_32_def* pfilefunc,voidpf filestream, ZPOS64_T offset, int origin)); +ZPOS64_T call_ztell64 _Z_OF((const zlib_filefunc64_32_def* pfilefunc,voidpf filestream)); void fill_zlib_filefunc64_32_def_from_filefunc32(zlib_filefunc64_32_def* p_filefunc64_32,const zlib_filefunc_def* p_filefunc32);

Brian Evans added a comment - 2017-01-19 02:22 Actually, they are changed for macro pollution. Gentoo Bug 383179 demonstrates why and a simple change of OF( to _Z_OF( fixes things. I'll write up a patch for CMakeLists.txt and the corresponding .h files to use the system libraries when available.

Andrew Hutchings (Inactive) added a comment - 2022-11-08 16:09 This appears to have been fixed by commit ID e4e801d4789d. If this is still an issue please reopen.