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 source. 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. `-Bsymbolic' 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 [EMAIL PROTECTED]