Re: About symbol versioning, soname bumps and symbols files.
On Sun, Apr 26, 2009 at 06:43:00PM +0200, Adeodato Simó wrote:
> > The generated, new symbols file looks something like:
Why exactly is this file "generated", and how? Symbols files don't work
very well if they aren't being deliberately maintained; it would be much
simpler to just use shlibs in that case.
> > Note, the three different versions of sctp_connectx (Base, VERS_1, VERS_2).
> > Now, I've never seen this technique used like this before.
> > So I'd very much appreciate any advice.
Well, cf. /var/lib/dpkg/info/libc6.symbols...
On second thought, don't. :)
> > 2.) Why are *there* different versions of sctp_connectx (Base and
> three
> > VERS_1 being and alias). I would have understood if there are two,
> > VERS_1 and VERS_2.
> 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.
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.
> > 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.
Cheers,
--
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
Reply to: