On Thu, 20 Dec 2007 21:44:19 -0800 Steve Langasek <vorlon@debian.org> wrote: > Consider two libraries, libfoo and libbar. libfoo depends on libbar, > references functions from it and uses some of libbar's types in its own > exported API. > > We assume the Debian-style libbar-dev, which ensures that the libbar headers > match the version of libbar.so on the system. > The pkg-config technique guarantee that, when an application links against > libfoo, it is also linked against libbar. Because of the preceding, this > guarantees that the application is linked against the version of libbar > whose ABI matches that of the headers used when building the application. > > But *nothing* here guarantees that the version of libbar the application is > linked against has the same ABI as the one libfoo itself linked against! ... until both the application and libfoo are rebuilt. So the issue here is triggering rebuilds of reverse dependencies of libbar? I can see this getting to be a big problem if the "application" in this example is actually another library. If libfoo actually doesn't build against libbar2 because of the API changes, the whole thing grinds to a halt. After all, libbar1->libbar2 could involve any level of changes to the API. If the application uses 5% of the libbar functions and the library uses 50%, it's easy to see that the library has a higher risk of needing intrusive source changes to build against the new libbar. The Gtk1->Gtk2 transition is still far from complete, KDE3->4 is current. Though the combination of libbar1 and libbar2 raises the chances of problems, forcing rebuilds whether the problem appears or not would seem to increase the problems of blocked transitions and hinder releases even further. > If > libfoo linked against libbar1, the pkg-config approach only ensures that > when your application is built against the libbar2 version of libbar-dev, > the resulting binary will depend on both libbar1 and libbar2 (despite not > using any symbols from libbar2). All this does is increase the chances of > segfaults or bad runtime behavior as a result of symbol clobbering. > > So the usage recommended by pkg-config upstream does nothing at all to solve > the problem it's supposed to, and instead causes other linkage problems. Maybe I've got this wrong but there would appear to be a few methods to fix this: 1. Incorporating the libbar SONAME into the libfoo package SONAME - as Simon Richter recommended - this could quickly end up with libany1-foo2-bar2-baz0-base4-pango0-... etc and I'm not convinced that this would actually help anyone if, for example, libbaz0 migrates to libbaz1 in a way that completely breaks libbar2. 2. A rebuild trigger mechanism that is separate from the library SONAME and the pkg-config files - an automated version of what happens now for requesting binNMU's ? Not as easy as it may sound - there's no guarantee that libfoo *can* build against libbar2. 3. A build-time hook that checks the entire dependency chain for duplicates and fails if a freshly built binary ends up linked to two versions of one source? (i.e. requiring a bug in whichever package is using libbar1 to upgrade to libbar2). That could lead to being unable to upload packages to fix other bugs. What is the correct solution? Is there a way that the current pkg-config *can* provide what upstream believe it already does? Even if pkg-config upstream are thinking of gentoo-type distributions, you'll still end up with a prebuilt libfoo depending on libbar1 and a freshly built application depending on libbar2, even using libbar1-dev and libbar2-dev (although at least that is more obvious). Maybe debtree could be useful here - or maybe edos-debcheck could be extended to look for problems like this. It should be apparent from the apt cache that the application uses libbar2 and libfoo but that libfoo depends on libbar1. Maybe there is a role here for deborphan or a similar tool as well - to scan an installation for not just orphaned libraries but duplicates as well. Getting back to the original thread, if applications and libraries each take more care not to link to spurious dependencies, it should be easier to identify the real problems instead of chasing red herrings where the application is linked to libbar2 and libfoo but actually only uses symbols from libfoo. I've just uploaded libqof1 that used the information from the new dpkg-shlibdeps to trim the dependencies of libqof1, excluding some libraries that were previously only brought in because of bugs in the libgda pkg-config data. It meant changing the QOF upstream to check for the particular functions that it needs instead of trusting the pkg-config data from libgda so that it could identify the correct dependency data for a public library provided by libgda but not exposed in the pkg-config data. (libgdasql). -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpITSQNdjJKr.pgp
Description: PGP signature