[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

libpng (again), testing and comments welcome

I have put new libpng packages online at
and I would appreciate some comments and testing with them.


These packages try to work around the (not so hard, but likely to
increase) libpng mess using versioned symbols, but without breaking
compatibility with other distributions and older versions of Debian. The
idea is quite simple : not enable versioned symbols when linking
software by default.

What *might* (see below) be broken by these packages :
- running software built with Debian's libpng10/libpng2 on other systems
(this may concern software linked with gdk-imlib1, see below) ;
- running Debian's libraries using libpng, taken from our .deb's, on
other systems.

What we can gain :
- software linking to both libpng10 and libpng12 can work (I'm only
aware of the plplot case) ;
- we can finally migrate some libraries that use libpng10 and were held
back by other libraries to libpng12 ;
- we prepare the next upstream major version bump instead of getting in
the same mess with more and more headaches every time.

How this is/will/would be achieved :
- libpng10 is built with versioned symbols ;
- 2 versions of libpng12 are built with the same SONAME ; the library in
libpng12-0 uses versioned symbols, but libpng12.so (or libpng.so) in
libpng12-dev is the other version, built without versioned symbols. The
symlink to the versioned-symbols enabled library is
libpng12-versioned.so (or libpng-versioned.so) ;
- our binary packages can then continue to link with -lpng ; they won't
require versioned symbols, but will run with the library having them,
which is not a problem ;
- our library packages will have to link with -lpng-versioned to get the

Random thoughts :
- Gdk-imlib1 doesn't link directly with libpng, but rather lets the
final application do it (against libpng10). Applications will still have
to do that against libpng10, but will be able to link with other
libraries using libpng12 (e.g. SDL) at the same time.
- This won't solve the case of the package foo linking with libpng and
with libbar, itself linking with libpng, as long as foo is not linked to
libpng-versioned itself. I suggest we leave the decision to use
versioned symbols or not to the package maintainer.
- Software linked with the versioned-symbols enabled library seem to
function properly even when the library on the system doesn't have
those. The dynamic linker only issues a warning. Could people with other
distributions test whether this is always the case ? If there are no
problems of binary interoperability with other distributions, we could
enable versioned symbols by default.
- The next major upstream version is probably not likely to get out
soon, so we can take all our time to do that transition smoothly,
rebuilding the libraries in a matter of months (or even more than a

Of course, I won't upload these packages without a clear consensus this
will lead to a better situation than the current one. The major drawback
of changing all library packages should be taken into consideration.


 .''`.           Josselin Mouette        /\./\
: :' :           josselin.mouette@ens-lyon.org
`. `'                        joss@debian.org
  `-  Debian GNU/Linux -- The power of freedom

Attachment: signature.asc
Description: PGP signature

Reply to: