[lsb-discuss] NSS: soname problems and compatibility issues
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"
> 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
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