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

Re: -Wl,--as-needed considered possibly harmful

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

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

Attachment: pgpWQbS9xe21i.pgp
Description: PGP signature

Reply to: