On Thu, Jan 03, 2002 at 05:48:53PM -0200, Henrique de Moraes Holschuh wrote: > On Thu, 03 Jan 2002, Ed Tomlinson wrote: > > and have created one (See 127215). From my perspective the problem > > seems to be the libpng3 changes the dependencies of qt2 and hense kde. > > It seems the fix is not to revert/fix libpng but to fix the qt > > dependencies however I get the impression that frustration is setting > > Yes. Actually, we have the same problem with every library that links with > another library that is likely to be used by an app.
So the consensus is that the libpng/libqt2 fiasco is due to having application A linked to shared libs L and M, while libL is also linked to (a different version of) libM: A -+-> libL ---> libM (version x) `-> libM (version y) where version x is not compatible with y, right? > The best example is libdb*, but there are others. libtiff, libpng, libsasl, > libz... Those would be examples of lib "M". Examples of lib "L" include the infamous libqt2 and imlib1, so the issue is of interest to anyone who uses KDE or GNOME. So: how should we best handle a major version change in libM? What do other "L"-type libraries do??? > You either make sure EVERYthing is linked against the same library versions If we go this route, how do we gracefully handle a bump in SONAME for libM? If an application is rebuilt with the new version of libM, it will break. If libL is rebuilt with the new version of libM, then all applications using libraries L and M will break. Clearly libL and all the application packages have to cooperate on the transition. One idea is for libL to rebuild and declare versioned conflicts with all its applications (that's what python recently did, isn't it?). But that balloons the size of the conflicts list for a popular library like libqt2. There must be a better way! (?) > or you must tell any libraries that > link to other libraries to use --symbolic dynamic linking, That sounds plausible --- is it really as simple as this? The info page for "gcc -symbolic" says "Only a few systems support this option." Are all Debian systems covered? > or you must use versioned symbols. What does this mean? Would it apply to libL or to libM? How would one implement this? > We actually need a Debian-wide (well, probably a LSB-wide) fix for the > problem. The same kind of breakage is expected to hit us again and again > until we do that. I agree. Suppose we limit our scope to Debian for the moment: what is currently done by the other lib"L"-type libraries in Debian? -Steve -- by Rocket to the Moon, by Airplane to the Rocket, by Taxi to the Airport, by Frontdoor to the Taxi, by throwing back the blanket and laying down the legs ... - They Might Be Giants