[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mozilla-crypto
Subject:    Versioning of NSS Shared Libraries
From:       Wan-Teh Chang <wtc () netscape ! com>
Date:       2000-12-29 19:10:21
[Download RAW message or body]

NSS will start to provide shared libraries (dynamic link libraries)
in the 3.2 release.  Here is a proposal of how version information
will be done for the NSS shared libraries.

Backward Compatibility

NSS shared libraries are guaranteed to be backward compatible with
previous minor releases.  For example, NSS 3.3 and 3.4 will be
backward compatible with NSS 3.2.

A major release represents some incompatible changes in the interface,
so NSS 4.0 won't be backward compatible with NSS 3.x.

Library Naming

There will be three shared libraries: nss (base), smime, and ssl.

The current plan is to use the same shared library naming convention
that NSPR is using.
- Unix: libnss3.so, libsmime3.so, libssl3.so, with SONAME (specified
  with the -h or -soname linker option) libnss3.so, libsmime3.so,
  libssl3.so.
- Windows: nss3.dll, smime3.dll, ssl3.dll, with import libraries
  nss3.lib, smime3.lib, ssl3.lib.

Note: the standard naming convention on Unix is to put the major version
number in the file suffix and create the versionless generic name as a
symbolic link.  For example, the nss (base) shared library would be
created
as follows:
    libnss.so.3  (the real file, with SONAME libnss.so.3)
    libnss.so   -->  libnss.so.3  (a symbolic link)

The nonstandard naming convention that we plan to use achieves the same
goals without having to create symbolic links.  I'd like to hear your
opinions on whether we should use the standard naming convention on
Unix.

Internal Library Version Information

We plan to implement a function NSS_VersionCheck in the nss (base)
shared
library that reports whether the actual (run-time) version of the shared
library is compatible with the expected (compile-time) version of the
shared library.
    extern PRBool NSS_VersionCheck(const char *importedVersion);

For example, if you build your application against NSS 3.2.1, your
application
would call NSS_VersionCheck("3.2.1").  At run time, if your application
picks
up NSS 3.3, the NSS_VersionCheck call will return true.  If your
application
picks up NSS 3.2, NSS_VersionCheck("3.2.1") will return false.

In addition, we plan to use platform-specific methods to embed version
information that can be retrieved by standard tools.

Unix:
- We will embed sccs and rcs strings that can be retrieved with the
 'what' and 'ident' commands.  The sccs string would look like this:
      NSS 3.2  Fri Dec 29 13:44:34 PDT 2000
  The rcs string would look like this:
      $Header: NSS 3.2  Fri Dec 29 13:44:34 PDT 2000
- We will use mapfiles/version scripts (on Solaris and Linux, at least)
  to add interface version definitions and the global symbols exported
  by each interface version.  The mapfile/version script would look
  like this:
      NSS_3.2 {            # NSS 3.2 release
          global:
              ATOB_AsciiToData;
              BTOA_DataToAscii;
              ...
          local:
              *;
      };

Windows:
- We will use a version-information resource that can be examined with
  Windows Explorer.

Exported Symbols

Symbols exported from the NSS shared libraries will be explicitly
controlled
with platform-specific techniques.  On Solaris and Linux, we use
mapfiles
(version scripts).  On Windows, we use module-definition (.DEF) files. 
If
you know how to control exported symbols on your platform, please let us
know.

Actions

If there is something else regarding shared library versioning that we
should
be doing, please let us know.  We welcome your comments on this
proposal.

[prev in list] [next in list] [prev in thread] [next in thread]