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

Jeff Licquia jeff at licquia.org
Thu Aug 28 08:44:21 PDT 2008

Wan-Teh Chang wrote:
> This is true, but libnss3.so tells me it's NSS 3.x, while
> libc.so.6 doesn't tell me it's glibc 2.  You actually need
> to know the history of libc on Linux to know what "6"
> means.
> This is why I think the libnss3.so soname (as opposed to
> libnss.so.3) is just a cosmetic issue.  Of course, I realize
> that I have seen libnss3.so so long that I could miss
> something obvious, such as people expect to see a
> number after .so in a soname.

In a sense, it's cosmetic; obviously, the dynamic linker doesn't refuse 
to link an "improperly" named library.

OTOH, it's a convention that's universally followed, and so people 
expect to see it.  When they don't, you get situations like the 
libnss3.so.1d thing in Debian.  People tend to assume that if you don't 
follow the convention, that's because you don't know what you're doing 
on Linux, and then helpfully "fix" it for you.

> I'm very interested in knowing what the "standard" soname
> naming convention is in LSB.  The examples that Mats
> gave showed that there are at least two soname naming
> convensions.

No, not really.  The convention is "libname.so.number".  There's no 
restriction on whether the library name contains dashes, numbers, etc.

The number after "so" is expected to start with 0 or 1, and is expected 
to increment with every backward-incompatible change.

(I have no idea where Debian's "d" comes from, unless it's an indication 
that this is Debian-specific.)

The fact that an ABI is stable is not considered sufficient reason to 
skip the trailing number.  PAM, for example, has been libpam.so.0 since 
the mid 1990s.

More information about the lsb-discuss mailing list