NSS shared libraries are versioned with the major
version numbers. For example, the base NSS shared
library in all NSS 3.x releases is named libnss3.so,
which is also the "soname" of the shared library.
Note that we put the major version "3" in a
nonstandard place in the library's name and soname
("libnss3.so" as opposed to "libnss.so.3"), but our
nonstandard naming convention accomplishes the same
goals. Also note that we don't have the common
symlink setup like this (using NSS 3.11 as an example):
real file libnss.so.3.11
symlink libnss.so.3 -> libnss.so.3.11
but this is a minor loss of functionality. If you
really insist, we can do something like this:
real file libnss.so.3.11
symlink libnss3.so -> libnss.so.3.11
The name "libnss3.so" is too widely known to change.
We also properly version our exported symbols. So we
are following the best practices of shared libraries
as closely as we can.
The reason only Mozilla (or rather, its PSM component)
ran into the problem after the system NSS was downgraded
is that PSM is linked with a NSS *static* library
(libcrmf.a), which references a new symbol with the
symbol version "NSS_3.11.1". After PSM is linked with
libcrmf.a from NSS 3.11.1, PSM contains a reference to
the new symbol. This is why PSM can't resolve the
symbol if the system NSS is downgraded to NSS 3.11.
So, we should keep in mind that the root cause of this
particular problem is the use of static library that
gets out of sync with its associated shared libraries.
Because of this incident, we will make it a higher
priority to convert libcrmf.a into a shared library.
Wan-Teh Chang
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
