[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.


-------------- 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