[lsb-discuss] NSS: soname problems and compatibility issues

Wichmann, Mats D mats.d.wichmann at intel.com
Wed Aug 27 11:03:25 PDT 2008

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

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

More information about the lsb-discuss mailing list