Unable to repair wheel that uses zlib-ng

[cgohlke]

Hello,

I am unable to repair wheels that contain C extensions compiled against the zlib-ng library.

The wheels, C extensions, and zlib-ng 2.2.4 library were built from source code on the quay.io/pypa/manylinux_2_28_x86_64:2025.07.27-1 container using cibuildwheel 3.1.3.

Zlib-ng was built without zlib compatible API (ZLIB_COMPAT=OFF) such that there are no conflicting symbols with the standard system zlib library.

The relevant output from auditwheel -v repair -w {dest_dir} {wheel} command is

DEBUG:auditwheel.policy:Package requires ZLIB_NG_2.1.0, incompatible with policy manylinux_2_28_x86_64 which requires 
{'ZLIB_1.2.5.1', 'ZLIB_1.2.2', 'ZLIB_1.2.3.5', 'ZLIB_1.2.5.2', 'ZLIB_1.2.0.2', 'ZLIB_1.2.9', 'ZLIB_1.2.2.4', 'ZLIB_1.2.0', 'ZLIB_1.2.2.3', 'ZLIB_1.2.0.8', 'ZLIB_1.2.3.3', 'ZLIB_1.2.7.1', 'ZLIB_1.2.3.4'}

Is ZLIB_NG_2.1.0 mistaken for ZLIB_* or is that intended?

Is there a workaround?

In the past, I reverted to auditwheel==4.0.0 on manylinux2014 but that seems to no longer work since the latest numpy requires manylinux_2_27_x86_64.

This issue affects the imagecodecs library.

Thank you!

[mayeut]

Is ZLIB_NG_2.1.0 mistaken for ZLIB_* or is that intended?

it's not intended, needs a fix to exclude ZLIB_NG_*.

Is there a workaround?

The only one I can think of would be to build zlib-ng as a static library for now.

[cgohlke]

Thank you for confirming. Linking to static zlib-ng does indeed work.