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_conne...@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/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org