minizip CMake build 32-bit

[aelray]

Hi,
on the develop branch it seems that minizip is being ported to CMake. Is there a reason why the new build system prevents builds for 32bit see this commit. The Makefile-based build system did not prevent this and we were happily using minizip as a 32-bit artifact.

[Vollstrecker]

werner@werner1:~/Devel/Build/zlib/32-bit$ make
[ 21%] Built target zlib
[ 43%] Built target zlibstatic
[ 45%] Built target zlib_example
[ 48%] Built target minigzip
[ 51%] Built target zlib_example64
[ 54%] Built target zlib_static_example
[ 56%] Built target static_minigzip
[ 59%] Built target infcover
[ 62%] Built target zlib_static_example64
[ 63%] Building C object contrib/minizip/CMakeFiles/libminizip.dir/ioapi.c.o
In file included from /home/werner/Devel/zlib/contrib/minizip/ioapi.h:74,
from /home/werner/Devel/zlib/contrib/minizip/ioapi.c:29:
/home/werner/Devel/zlib/contrib/minizip/ints.h:55:5: error: #error "no 64-bit integer"
55 | # error "no 64-bit integer"
| ^~~~~
/home/werner/Devel/zlib/contrib/minizip/ioapi.h:75:9: error: unknown type name ‘ui64_t’; did you mean ‘ui32_t’?
75 | typedef ui64_t ZPOS64_T;
| ^~~~~~
| ui32_t
/home/werner/Devel/zlib/contrib/minizip/ioapi.c: In function ‘call_zseek64’:
/home/werner/Devel/zlib/contrib/minizip/ioapi.c:46:29: error: comparison of integer expressions of different signedness: ‘uLong’ {aka ‘long unsigned int’} and ‘ZPOS64_T’ {aka ‘int’} [-Werror=sign-compare]
46 | if (offsetTruncated != offset)
| ^~
cc1: all warnings being treated as errors
make[2]: *** [contrib/minizip/CMakeFiles/libminizip.dir/build.make:79: contrib/minizip/CMakeFiles/libminizip.dir/ioapi.c.o] Fehler 1
make[1]: *** [CMakeFiles/Makefile2:478: contrib/minizip/CMakeFiles/libminizip.dir/all] Fehler 2
make: *** [Makefile:166: all] Fehler 2

[aelray]

Ok, thx for the clarification. Seems like I missed something.

[aelray]

Can't this be due to a local change in zlib be24a8f? This is not part of "upstream" minizip.

[aelray]

I was able to successfully compile tag 1.3.1 with:

 CFLAGS="-m32" LDFLAGS="-m32" ./configure

[Vollstrecker]

I'm no (real) code-guy. Maybe this wasn't in the test when it was comitted.

[aelray]

The previous version did this in ioapi.h:

    #include <stdint.h>
    #define ZPOS64_T uint64_t

and this seems to compile to 32-bit. The new (custom and compiler-agnostic) way in ints.h does not compile to 32-bit.

[madler]

So is ints.h failing to find a 64-bit integer when there is in fact a 64-bit integer available? What system and compiler is this on?

[aelray]

Usual linux x64 (Fedora 42, gcc 15.1.1) cross compiling to x86.

To my understanding uint64_t is available in 32-bit but it is probably represented using 2 32-bit registers.

[madler]

What options are used to cross-compile to x86?

[aelray]

For the old version this worked to configure

CFLAGS="-m32" LDFLAGS="-m32" ./configure

followed by a call to make.

For the new CMake-based setup I integrated the develop branch via FetchContent_Declare() in an existing CMake project in which I target x86.

[Vollstrecker]

cmake works the same way as configure in this scenario. And as it's a problem way before linking setting CFlags would suffice.

[aelray]

I'm using a CMakePresets.json in which the following is set:

"cacheVariables": {
    "CMAKE_C_FLAGS": "-m32",
    "CMAKE_CXX_FLAGS": "-m32",
    "CMAKE_SHARED_LINKER_FLAGS": "-m32"
}

This should lead to a similar behavior compared to configure

[madler]

For the old version this worked to configure

CFLAGS="-m32" LDFLAGS="-m32" ./configure

followed by a call to make.

For the new CMake-based setup I integrated the develop branch via FetchContent_Declare() in an existing CMake project in which I target x86.

Have you tried configure on the develop branch?

[aelray]

Yes 32-bit configure still works on the develop branch.

[Vollstrecker]

I've been digging deeper. I remember testing this and just copiying the CFlags from the C-Standard action and the first one was -std=c89. It seems that this error occurs only with c89 and iso9899:199409. String with gnu89 or c99 everything works.

So we could either check on given CFlags for these 2 values and bail out. Or we could demand at least C99 and atop if it's not met. Or we can just remove that check and mention in the docs that c89 isn't supported anymore (given it was anytime ealier).

[madler]

Why specify the std at all?

[Vollstrecker]

That's what you have to ask the author of this line. I just saw that it doesn't work and deactivated it (and a bit too much I guess). It works on the actions as libminizip isn't built there.