Release 1.3.2 tag to support libpng >1.6.40

[gitoss]

Not to put too fine a point on it :-)

Releasing a zlib 1.3.2 tag would be nice, or software that relies on a tag to pull zlib is stuck with an outdated libpng 1.6.40 version: https://github.com/AOMediaCodec/libavif/blob/main/cmake/Modules/LocalZlibpng.cmake

[madler]

What is the issue with libpng?

[gitoss]

What is the issue with libpng?

I dunno, I just read the comment in the file above that zlib 1.3.1 is incompatible with png > 1.6.40 - I you want to track the actual problem, you'd have to ask the libavif dev(s).

I just notified you here because I recommended switching to zlib-ng (the dev mentioned chrome zlib) to not have these kinds of problems: AOMediaCodec/libavif#2496

[Neustradamus]

@madler: Can you look it?

Thanks in advance.

[gregg-platogo]

grpc/grpc#35855 also related

[vrabaud]

Hi, stumbling here to see if a new release is coming up :) I wrote the comment mentioned by @gitoss. libpng's CMake got cleaner in 1.6.41 (cf https://github.com/pnggroup/libpng/blob/812c34c13c27a963073e546c720f5a7b88b1ed00/CHANGES#L6147) and when installing it, we get the error:

CMake Error: install(EXPORT "libpng" ...) includes target "png_static" which requires target "zlibstatic" that is not in any export set.

which requires https://github.com/AOMediaCodec/libavif/blob/906a8a5bd18a744f0e2e603e1841c1ef5e712677/cmake/Modules/LocalZlibpng.cmake#L61-L64 to work, but necessitates f1f503d to be in an official release

[Vollstrecker]

There's the problem with submodules and deps between them. f1f503d is over a year old and superseeded. You define ZLIB::ZLIB for zlibstatic. ZLIB::ZLIB is the alias for the shared version and you'll get conflicts when current state get's release or you update your submodules. And yes, zlibstatic is not and will not be part of any exportset. For this purpose are the aliases created that work as submodule and when installed under the same name.

shared -> ZLIB:ZLIB
static ->ZLIB::ZLIBSTATIC

[vrabaud]

Thx for the analysis @Vollstrecker . Indeed, ZLIB::ZLIB is an alias to zlibstatic as this is what png_static needs: https://github.com/pnggroup/libpng/blob/812c34c13c27a963073e546c720f5a7b88b1ed00/CMakeLists.txt#L647 . This seems to be what people do (cf pnggroup/libpng#600 for a similar solution). I guess once ZLIB::ZLIBSTSTATIC is in an official release, libpng will have to be fixed too.

[Vollstrecker]

This is the perfect example. It fetches without tag, which means master, and the example fetches a commit that fixes something, but both don't export the complete config with targets. FindZLIB finds something, but static or shared is not specified anywhere. So yes, after this is released and hits distros, many projects out there need to get fixed, or better need to drop their workarounds.

[Neustradamus]

Any progress on this ticket?

[dridi]

Unrelated to the libpng problem, it has also been more than a year since the introduction of the deflateUsed() function. I have been eagerly waiting for it to start showing up in software distributions and then in other projects providing a zlib-compatible interface but it needs to be part of a zlib release first before it can spread.

Any chance of seeing a 1.3.2 release (or 1.3.1.1 based on the git history) with the pending changes from the develop branch soon?

Thanks in advance.