It looks like MSYS2 is compiling zlib with _LARGEFILE64_SOURCE in order to generate the 64-bit capable gz<func>64 functions ... but then z_off64_t is getting set to z_off_t, which makes all the functions 32-bit anyway.</func>
Is this a deliberate choice, or is this a bug?
It looks like zlib should be being compiled with either _FILE_OFFSET_BITS=64 or _LFS64_LARGEFILE, in addition to _LARGEFILE64_SOURCE.
If it is compiled with _LFS64_LARGEFILE, then you'd need to patch zconf.h.in, line 484 to change ...
#if !defined(_WIN32) && defined(Z_LARGE64)
to ...
#if defined(Z_LARGE64)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It looks like MSYS2 is compiling zlib with _LARGEFILE64_SOURCE in order to generate the 64-bit capable gz<func>64 functions ... but then z_off64_t is getting set to z_off_t, which makes all the functions 32-bit anyway.</func>
Is this a deliberate choice, or is this a bug?
It looks like zlib should be being compiled with either _FILE_OFFSET_BITS=64 or _LFS64_LARGEFILE, in addition to _LARGEFILE64_SOURCE.
If it is compiled with _LFS64_LARGEFILE, then you'd need to patch zconf.h.in, line 484 to change ...
to ...
Can you send a pull request on GitHub for this change? It would have a greater chance of being noticed.
Either way, I can't say if it's deliberate. Maybe zlib developers will know why there's an anti-Windows guard there.
Worse, Z_LARGE64 doesn't even get defined.