Thomas Klausner wrote:
> On Mon, Apr 17, 2006 at 10:16:05AM +0200, Bernd Ernesti wrote:
>> The difference comes from a linker script used for the libpng12 library.
>> libtool is called with this option: -Wl,--version-script=libpng.vers
>>
>> and that script doesn't have some entries which will be gone, as noted
>> in libpng.txt:
>>
>>  The old libpng functions png_read_init(), png_write_init(),
>>  png_info_init(), png_read_destroy(), and png_write_destroy() have been
>>  moved to PNG_INTERNAL in version 0.95 to discourage their use.  These
>>  functions will be removed from libpng version 2.0.0.
> 
> Ok, so cups uses a deprecated API. We should link it against the old libpng
> then. I'll take a look.
> Did you find anything else break because of that?

I expect lots of breakage on this one.  How well does the new libpng 
support the deprecated API?  I couldn't find any documentation on how to 
use the deprecated functions.  It looks like maybe we can just pass 
-DPNG_INTERNAL to the compiler to make it use the deprecated functions, 
but I haven't tested this yet.  Since CUPS is breaking, it looks like 
this support isn't so good.

If the old API support isn't good, I think what we should do is to have 
two PNG packages, png and png12, or perhaps to be more forward looking 
png (>=1.2.9) and png-old (<1.2.9).  Packages that want the old 
interface and ABI and link against png-old, which will supply just the 
headers and libraries.  The png package would be built with 
--without-libpng-compat so that it doesn't try to make those troublesome 
symlinks to its libraries and the Makefiles would be patched to prevent 
creating symlinks to the headers and *.pc files.  These two packages 
install completely different files so they won't conflict and can be 
installed simultaneously.

If the old API support *is* good, then I think we should still just make 
the png package build --without-libpng-compat and not install those 
symlinks, and then just use buildlink tricks to make the new png package 
look like the old one for the benefit of software that hasn't yet 
switched to the new PNG API.  This is kind of like how we currently 
handle packages that use the old DES API when using OpenSSL -- the 
packages that want to use the old PNG API would set USE_OLD_PNG_API in 
the package Makefiles.

Does this plan sound good?  We would still need to find out how well the 
png package supports the old API to decide which way to go.

	Cheers,

	-- Johnny Lam <jlam@pkgsrc.org>