Subject: Re: Warning: graphics/png is currently broken
To: Bernd Ernesti <veego@NetBSD.org>
From: Johnny Lam <email@example.com>
Date: 04/17/2006 10:54:48
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
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.
-- Johnny Lam <firstname.lastname@example.org>