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

Re: Bug#127252: -unstable compiled against the wrong libpng

On Tue, Jan 01, 2002 at 07:39:07PM +1100, Mark Purcell wrote:
> Btw, this appears to be a major backwards incompatibily problem
> between libpng2 -> 3 which effects lots and lots of packages.
> The solution is rather simple, requiring recompilation to
> get the correct linkage to libpng3, but it would of been nice to
> see some dicussion on debian-devel before the upload of
> libpng3 to unstable 'broke' all our pacakges.

libpng3 can't be at fault directly, since it correctly has a different
soname. For instance, knews (not a KDE package, despite the name) still
depends on libpng2 on i386 and still works fine, and the libpng2
development libraries are still available so it can still be built from

The problem appears to be that libqt2 now links to libpng3 rather than
libpng2. When the dynamic linker loads a QT-dependent application still
linked against libpng2, it overrides libqt2's png symbols with the png
symbols defined in the application, so any png calls from inside qt will
crash. Recompiling all applications to deal with this feels like the
wrong answer; perhaps qt-x11 should be built with something like '-B
symbolic' instead.

     When creating a shared library, bind references to global symbols
     to the definition within the shared library, if any.  Normally, it
     is possible for a program linked against a shared library to
     override the definition within the shared library.

I'm also a little confused by why so many KDE applications link to
libpng directly. Picking kdeutils at random, the only instances of
'png_' or 'png.h' anywhere in the source tree are in
admin/acinclude.m4.in, yet -lpng is on the link line and so all the
binary packages built from kdeutils depend on libpng directly. Why?

Colin Watson                                  [cjwatson@flatline.org.uk]

Reply to: