[MDEV-11809] Cannot compile Connect SE - connect/ioapi.h:135:51: error: expected initializer before ‘OF’ Created: 2017-01-16  Updated: 2022-11-08  Resolved: 2022-11-08

Status: Closed
Project: MariaDB Server
Component/s: Compiling, Storage Engine - Connect
Affects Version/s: 10.0.29
Fix Version/s: 10.0.30

Type: Bug Priority: Major
Reporter: Brian Evans Assignee: Andrew Hutchings
Resolution: Fixed Votes: 0
Labels: None
Environment:

Gentoo GCC 5.4.0

Attachments: File build.log     Text File emerge-info.txt    

 Description   

Complete build log attached.

Errors on:

[ 11%] Building CXX object storage/connect/CMakeFiles/connect.dir/mycat.cc.o
 
In file included from /var/tmp/portage/dev-db/mariadb-10.0.29/work/mysql/storage/connect/unzip.h:55:0,
 
                 from /var/tmp/portage/dev-db/mariadb-10.0.29/work/mysql/storage/connect/tabzip.h:12,
 
                 from /var/tmp/portage/dev-db/mariadb-10.0.29/work/mysql/storage/connect/mycat.cc:99:
 
/var/tmp/portage/dev-db/mariadb-10.0.29/work/mysql/storage/connect/ioapi.h:135:51: error: expected initializer before ‘OF’
 
 typedef voidpf   (ZCALLBACK *open_file_func)      OF((voidpf opaque, const char* filename, int mode));



 Comments   
Comment by Olivier Bertrand [ 2017-01-17 ]

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.

Comment by Brian Evans [ 2017-01-18 ]

@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

Comment by Brian Evans [ 2017-01-18 ]

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

Comment by Olivier Bertrand [ 2017-01-18 ]

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.

Comment by Brian Evans [ 2017-01-19 ]

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);

Comment by Brian Evans [ 2017-01-19 ]

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.

Comment by Andrew Hutchings [ 2022-11-08 ]

This appears to have been fixed by commit ID e4e801d4789d. If this is still an issue please reopen.

Generated at Thu Feb 08 07:52:49 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.