[lsb-discuss] NSS: soname problems and compatibility issues
Robert Relyea
rrelyea at redhat.com
Wed Aug 27 11:18:08 PDT 2008
Wichmann, Mats D wrote:
>> NSS uses the built in linux SO versioning scheme for this.
>>
>
> I think the Debian complaint stems from it not really doing this.
> Normally, libraries are provided with a version suffix, and with
> an soname branded into the library. When you link against a
> library, the soname is added as a requirement for the binary.
> But the soname in, for example, the Fedora 9 copy of libnss3.so
> is just "libnss3.so" - there's none of the usual versioning,
> as in say "libc.so.6" or "libglib-2.0.so.0" (numerical suffix
> serving as the versioning) - it appears to be this that Debian
> decided was their policy to add.
>
Right, that versioning is there because Linux libraries do not normally
have binary guarantees between various releases. An old library linking
with a new .so would fail because the new .so has changed the size of
some important data structure in the API.
NSS guarantees that won't happen.
The issue we got from Debian was different. That they were guarding
against newer applications running on older systems. They were not more
specific than that.
>
>> NSS uses .def files to control exports of symbols. Each symbol is
>> tagged with the release of NSS that it was first exported. This is to
>> prevent
>> the compatibility issue above, however the application in question
>> stripped that information. The correct fix is not to strip that
>> information (which is implemented in the RH systems now).
>>
>
> But this is a different question - this is not library versioning,
> but symbol versioning. The LSB is using libnss3/libssl3 symbol
> versioning, and once the proper library is located, it doesn't
> seem we're having any problems with this part of the draft spec, it
> appears to be consistently implemented.
>
So the point is it doesn't matter which library. If you are an
application linked against the old library, there is no problem using
the new library. If you are a new application using the old API, then
it's still OK to use the old library. If you use new API functions, you
need to automatically upgrade to the new version of the library. Symbol
versioning tells you what minimum version of NSS you need to run.
bob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3420 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.linux-foundation.org/pipermail/lsb-discuss/attachments/20080827/d1aae7d9/attachment.bin
More information about the lsb-discuss
mailing list