Steve Langasek wrote:
> 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.
Nah, this was just badly explained. I usually carefully review and update the
symbols file. As in this case all symbols changed, I did a simple search and
replace (which also explains that I uncorrectly updates sctp_connectx@Base)
>
>>> 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.
This is the output of objdump:
000009b0 g DF .text 00000098 (VERS_1) sctp_connectx
000009b0 g DF .text 00000098 (Base) sctp_connectx
The prototypes for the functions are
int __sctp_connectx(int fd, struct sockaddr *addrs, int addrcnt)
extern int sctp_connectx_orig (int)
__attribute ((alias ("__sctp_connectx")));
So they are indeed different. I can only assume that __attribute ((alias
is some kind of black magic, so this doesn't really matter. But would appreciate
a proper explanation of course ;-)
>
>>> 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.
Thanks for spotting this. That's indeed a result of my search and replace.
> 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.
That's interesting. I ran the lksctp-tools 1.0.9 binaries against the libsctp1
1.0.10 lib, and didn't notice any warnings or problems.
As dato already mentioned, it's not really that big of a deal, as the only
binary package depending on libsctp is lksctp-tools itself, which is built from
the same source package.
Nonetheless, I wanted to better understand what's going on here and your
comments so fare were already very helpful.
Cheers,
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Attachment:
signature.asc
Description: OpenPGP digital signature