Re: About symbol versioning, soname bumps and symbols files.
+ Steve Langasek (Mon, 27 Apr 2009 22:13:57 -0700):
> On Sun, Apr 26, 2009 at 06:43:00PM +0200, Adeodato Simó wrote:
> > I’m unsure why assigning VERS_1 to all symbols works for preserving
> > compatibility, whereas old binaries use symbols not associated with any
> > version node (i.e., @Base). Maybe the first defined version node gets to
> > “answer” to all requests that come without a version node attached. :-)
> > It’d be nice if somebody could explain.
> > But, if that’s true, I don’t know why there have to exist both a @Base
> > and @VERS_1 versions of sctp_connectx. I’ll also note that the @VERS_1
> > has a different prototype than the aliased function!
> Because the earlier library used unversioned symbols, any programs depending
> on this lib will have references to an unversioned "sctp_connectx" symbol,
> which will be resolved to an "arbitrary" symbol whose name matches. The
> explicit "Base" symbol, as provided by:
> > __asm__(".symver __sctp_connectx, sctp_connectx@");
> ... is needed so that objects linked against the pre-versioned lib resolve
> deterministically.
Yes, I understand that, and was what I thought initially. But then, I
didn't understand why all other symbols were migrated to have one only
version... in VERS_1.
But my question quoted above "what will make apps refering to
unversioned symbols pick up the symbols from VERS_1 automatically" still
stands, though. :-)
Oh, or maybe you answered already: an unversioned reference resolves to
an arbitrary version, unless there's a version binded to @Base? Does
this mean that, if another symbol was to be updated (into VERS_2, eg.,
or VERS_3), the same `.symver foo, foo@` would have to be used? What's
the point of having every symbol on VERS_1, then, and why weren't they
kept on @Base directly, adding only sctp_connectx to VERS_1?
> However, if the prototype for __sctp_connectx() doesn't match the prototype
> for sctp_connectx_orig(), then... I'm pretty sure that's a bug in the lib.
Okay, we can send mail to the patch author later.
> > > 3.) Should I just update the symbols file as shown above and not worry?
> Well, at least this entry:
> sctp_connectx@Base 1.0.10+dfsg
> is wrong, because that symbol was already present before, so (barring ABI
> bugs as mentioned above) the minimum version req for it shouldn't be bumped.
> But if every other symbol suddenly has a "VERS_1" symbol version, then
> anything linking against those will be unhappy when run against the
> pre-versioned lib anyway (throwing warnings but not errors), so that's a
> minor point.
Right. When reading the symbols file propsed by Michael, I thought
something in the lines of "ok, every symbol bumped because the new
library is backwards but not forwards compatible, so it's kind of a
shlibs bump". The sctp_connectx@Base version just got lost in the noise
of having every other symbol bumped, and it's (while incorrect) very
minor indeed.
(On other news, libsctp1 has exactly one reverse dependency, which comes
from the same source package.)
Thanks, Steve!
--
- Are you sure we're good?
- Always.
-- Rory and Lorelai
Reply to: