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

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

On Tue, 1 Jan 2008 23:17:50 -0800
Steve Langasek <vorlon@debian.org> wrote:

> On Wed, Dec 26, 2007 at 01:11:40PM +0000, Neil Williams wrote:
> > I think I'm doing this already - if libfoo1 implements and exports types
> > from libbar2 and libbar2 moves to libbar3, I would expect to have to
> > port libfoo to libbar3 and this would usually cause a SONAME bump in
> > libfoo.
> > Have I got these possible scenarios correct:
> > 1. libfoo depends on libbar2 without exporting libbar symbols. libfoo
> > can migrate to libbar3 with internal code changes and if these do not
> > require changing any libfoo interfaces, libfoo needs no SONAME bump.
> No, "exporting libbar symbols" is not the right line to draw.  The right
> line is the one I already identified, namely, "libfoo uses some of libbar's
> types in its own exported ABI".

That makes more sense, thank you.

> > Does libfoo need to use versioned symbols to cope with this
> No, libbar does, as the library which has other libraries for
> reverse-dependencies.

(codehelp has a light bulb moment of clarity). :-)
> > 2. libfoo depends on libbar2 and exports some libbar symbols in
> > libfoo-dev. libfoo can migrate to libbar3 with only internal code
> > changes because it only exports a portion of the libbar API that has not
> > actually been changed in the libbar2->libbar3 transition. libfoo needs
> > to export libbar in the libfoo --libs data. Is a SONAME bump needed in
> > libfoo even though *none* of the libfoo interfaces have changed? As
> > upstream for libfoo, I would not normally make a SONAME bump in this
> > situation.
> If libfoo's exported ABI hasn't changed, then any package name or soname
> change is gratuitous and should be avoided.


> > 3. libfoo depends on libbar2 and needs to make changes to its own
> > interfaces to cope with the libbar transition or needs to export symbols
> > from the new libbar API and therefore makes a SONAME bump. No problem
> > here except ensuring that applications transition to both API's at the
> > same time. Can be enforced by making libbar-dev conflict with the old
> > libfoo-dev or making the new libfoo-dev depend on the new libbar-dev
> > version.
> Requires disruptive name changes to libbar-dev which affect all packages
> that build-depend on it, and is therefore again inferior to implementing
> symbol versions up front.


> Because *all* libraries which have other libs as reverse-dependencies should
> implement symbol versioning, precisely as the shortest path for reliably and
> permanently addressing the various issues we're discussing.
> It *is* libbaz's fault for having an ABI-breaking change.  And based on
> history, it is only reasonable to assume all such libraries are guilty, and
> demand that they use symbol versioning in anticipation of such future ABI
> changes.

OK, I'm doing this upstream for one of my packages - following threads from:

That gave me a basic versioning addition to the library, a diff of
objdump -p shows:
+Version definitions:
+1 0x01 0x06077991 libqof.so.1
+2 0x00 0x0f307023 LIBQOF_0.7.3

(I'm not putting the history of the symbols into the file at this stage
- no new symbols are added in the new version so the libqof.ver file is
simply marking all as global. I could add historical data - is there any
benefit in that?)

That's upstream covered, it appears I also need debian/libqof1.symbols
from http://qa.debian.org/cgi-bin/mole/seedsymbols ? If I had done
symbol versioning correctly upstream, shouldn't dpkg-shlibdeps be able
to create the necessary data itself? I don't provide a .shlib file of
my own at this stage.

(A SONAME bump is due in this library fairly soon so I want to get
symbol versioning into libqof1 prior to the ABI change.)

> No.  You seem to agree that each soname change of a library near the bottom
> of the stack should not propagate its way up the stack to affect other
> libraries that themselves are not affected by the ABI change, but you again
> overlook (or disdain) the impact that this has on partial upgrades if we
> don't require those base libraries to use symbol versioning. 

It was an oversight. Sorry.


Neil Williams

Attachment: pgp5W6o1uhcFd.pgp
Description: PGP signature

Reply to: