[Pkg-xmpp-devel] gsasl_1.4.0-2_i386.changes REJECTED

[Simon Josefsson]

cascardo at minaslivre.org writes:

>> Yes, I'm beginning to suspect this is the only way out -- however it is
>> very unfortunate that ADDING symbol versioning to a shared library
>> actually breaks the ABI.  Compare libidn, the API has been stable since
>> 2002 or 2003 or so, but adding symbol versioning this breaks.  It would
>> be nice to find a way were old applications can also find the old
>> symbols in a versioned library.
>> 
>
> I agree. I ended reading gnu libc loader code to understand the bug
> someone reported and ended finding out it was due to symbol versioning.
> I may dig out the code again and point out the section to blame for
> this. But I think the best thing to do in case it's not possible to not
> break the ABI is to just stay out of symbol versioning until you have to
> break it for any other reason.
>
>> I'm going to ask on the gnulib list if anyone has any bright ideas here.
>
> If you find out anything, please tell. I'd like to know.

I have posted this plea for help now:

http://permalink.gmane.org/gmane.comp.lib.gnulib.bugs/20569

One question is that if it makes sense to revert to unversioned symbols
now that applications are already linked to versioned libraries.  I
would need to increment the shared library version for that change too,
as far as I can tell, and then I could as well increment the shared
library version AND continue to use versioned symbols in that new ABI.
Incrementing the shared library version is arguable what I should have
done when starting to use versioned symbols, though.

There could be some speed advantages in symbol versioning, but I'm
wondering if it is really worth these pains.  I hope I'm just missing
some basic insight...

Btw, is this mailing list archive somewhere?

/Simon