From: Kenneth J.Davis (jeremyd@computer.org)
Date: Thu Aug 22 2002 - 17:16:49 EDT
From looking at their page it appears the 1.2.4 release broke
binary compatibility from the previous releases, hence the
requirement to bump the major version of the DLL (shared libary).
So the 1.2.3 (what we currently use) is the last of libpng2
line and 1.2.4 starts the libpng3 line.
From glancing at their brief change log it looks like it
fixed some memory leaks and added few more safety checks,
and added a new API to allow en/dis abling some optimizations
at runtime. If the interface portion we use did not change
then for those platforms that statically link to libpng
(i.e. Windows) then we can start using libpng 1.2.4 as soon
as someone feels like doing so; for other platforms that
link to a dynamic DLL [shared library] then adding such
a dependency seems to be something that should wait as
apparently there are some issues with applications using
libpngX and using a library that also uses libpng, but
is linked to libpngY causing segfaults. Where X is 2 or 3
and Y is the other (3 or 2). So a Unix/Linux distribution
is likely only to include libpng2 for a while and later
only libpng3.
Anyway, all this is explained on libpng's page and the
handy google link provided by Alan.
Jeremy Davis
jeremyd@computer.org
"Mike Nordell" <tamlin@algonet.se> wrote on 8/22/2002 9:50:15 AM:
>
>Alan Horkan wrote:
>
>> i did not realise there was a libpng3, but the real developers probably
>> know about it. (i have cc'ed the developer list)
>
>???
>Last I checked (like, now) there's but a libpng 1.2.4.
>
>Where does the "3" come from? Is it perhaps to reflect a binary dist's ABI
>compatibility with with GCC C++ 3.x (which is incompatible with itself
>within one version number)?
>
>/Mike
This archive was generated by hypermail 2.1.4 : Thu Aug 22 2002 - 17:35:31 EDT