Summary: | Changes required with libPNG ABI version 1.5 | ||
---|---|---|---|
Product: | Ghostscript | Reporter: | CdeMills |
Component: | Graphics Library | Assignee: | Chris Liddell (chrisl) <chris.liddell> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | chris.liddell |
Priority: | P4 | ||
Version: | 9.02 | ||
Hardware: | PC | ||
OS: | Linux | ||
Customer: | Word Size: | --- | |
Attachments: |
Conditionaly use the 1.5 ABI, if present
New version same, but as context diff current HEAD gdevpng.c revised for libpng 1.5.x another revision of gdevpng.c |
Description
CdeMills
2011-07-06 20:55:27 UTC
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 |