Hello, the pointers png_ptr and info_ptr have been hidden in libpng-1.5. Enclosed is a patch in order to compile gdevpng.c. I made the distinction between pre-1.5 and 1.5 calls by testing for PNG_LIBPNG_VER_MINOR < 5. Changes are straightforward, it is a matter of using the new interface. Please incorporate the patch, it will help peoples wanting to compile ghostscript using the system-wide libpng. Regards Pascal Dupuis
Created attachment 7646 [details] Conditionaly use the 1.5 ABI, if present
Created attachment 7647 [details] New version Inspirated from the patch coming from NetBSD. Do not dynamically allocate palette.
Created attachment 7648 [details] same, but as context diff
Created attachment 7655 [details] current HEAD gdevpng.c revised for libpng 1.5.x Hi, Thanks for the patch, unfortunately, the gdevpng.c in our git master/HEAD is sufficiently changed from the version against which your patch was made that it won't apply any more. However, using it as a "cheat sheet", I've revised our file: would you mind sanity checking my 1.5.x changes (I attached the full source)? I've reorganized things a bit to try to keep the 1.5 vs pre-1.5 changes relatively localized, also there's a couple of places with an empty "#if PNG_LIBPNG_VER_MINOR >= 5" conditional compile - I've done that so that all the conditions are the same. Chris
Created attachment 7656 [details] another revision of gdevpng.c I noticed some of the function calls weren't in the right order, so here's a revision which fixes that.
(In reply to comment #5) > Created an attachment (id=7656) [details] > another revision of gdevpng.c > > I noticed some of the function calls weren't in the right order, so here's a > revision which fixes that. Hello Chris, the code as you wrote it is indeed cleaner. Go for it. I dived it this file in the first place because I compiled ImageMagick and linked it against libgs (I built and installed the shared libs). The resulting executable was linked against libpng-1.5, and failed when trying to visualise png. With gdb, I traced the failure inside the code in libgs, it goes as follows: - ImageMagick is build and linked against libpng-1.5 - GhostScript comes with its own source of libpng-1.2 - by defining "PNG_INTERNAL" at line 40 of gdevpng.c, the internal interface of the libpng embedded inside libgs is re-exported. This way, rendering png images with ImageMagick failed because the first calls to libpng used the 1.5 (external) version, then the 1.2 (gs-embedded) version, which was detected as a version mismatch. Disabling this 'PNG_INTERNAL' define solved the problem. I tried by building libgs either out-of-the-box, either removing the sources of linpng (and others) from the ghostscript build directory. Both options solved the ImageMagick issue. Could you please test if you can remove this define ? Regards Pascal
I had a look over weekend, and I certainly can't see any reason in the current, nor historical code for having PNG_INTERNAL defined. My *guess* is that it was required to work around some libpng limitation that pre-dates our current repository history. I'll consult with my colleagues on the Ghostscript team about that, but I don't consider is an intrinsic part of *this* bug report (if you really want you can raise a separate bug - or just trust my sometimes flaky memory to remember it!). For now, I will commit the libpng 1.5.x API changes, and then close this bug. Chris
The 1.5.x changes are in commit: ee688b964bee8f9562ce92835b2478f88b0dbe31 http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=ee688b