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

[Steve Langasek <vorlon@debian.org>]

On Fri, Dec 21, 2007 at 10:55:32AM +0000, Neil Williams wrote:
> 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?

No.  That doesn't cause previously released binaries to blink out of
existence.

What's required is to ensure that there's a package rename each time
libfoo's ABI changes, including when the libfoo ABI change is caused by type
changes in the underlying lib.  This is essentially the general case of the
c102, c2, c2a, and ldbl transitions that we've been through for compiler
changes over the past few years; in theory we should be able to accomplish
these transitions for libraries with fewer reverse-dependencies than
libstdc++ with significantly less pain, as long as library maintainers are
forewarned.

But once the package name change is handled, the rebuild of reverse-deps
follows naturally.

> 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.

Then either libbar2 becomes libbar3 at the same time, or libbar becomes
unsupported (and the stack above it has to be ported or else it's not
releasable), or libbaz needs to support symbol versioning to permit
coexistence of the two versions in the same address space.

> 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.

Wrong for the reasons stated above.

> 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.

Doesn't sound like it actually solves the problem that needs solving for the
same reasons as option 2. above, but could be usable if fleshed out
appropriately.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org