John Bowler

There is no memory leak here, the program has exited with a fatal error (and this is the correct behavior).

See the explanation in #350.

The fix for #350 may be sufficient. It does not seem to have been merged. The problem is that the "else" clause on line 3985 which tests suffix != NULL...

I don't know what was being run here because the "apt-cache" screenshot is for the pngtools package; the one with the real pngcp, not the libpng one. It looks like...

I suggest adding -fexceptions to all libpng builds with compilers that support this. This was the way I always built libpng anyway. It will change the default behavior on almost...

Yes; the transforms do not always compose correctly. I identified a number of cases (I'm not sure if this is one, probably not because memory format conversions are not a...

This seems to me to be an Apple bug. Apple systems use multi-lib builds which compile single executables for use with multiple ABIs. This is handled in libpng by not...

I think this happened somewhere else too. Maybe it was this. Since it isn't possible to tell which version of zlib is available without an OS specific check the suggested...

> libpng shouldn't support macOS at all libpng doesn't support MacOS: this bug has been sitting here since Nov 07, 2017, @ctruta's last comment was on Nov 14, 2018. Meanwhile...

@sgowdev, @vadz, @ctruta This bug is just about **a warning message generated during the build**, isn't it? _There's absolutely no problem in the code generated with the currently libpng 1.6...