452873 - Use standard shared library soname libnspr4.so.4.

Status: NEW

(NSPR :: NSPR, defect)

Description

[Wan-Teh Chang]

Attachment: Preliminary patch

The attached patch is a quick-and-dirty patch I wrote
to use standard shared library soname libnspr4.so.4,
libplc4.so.4, and libplds4.so.4.

It creates the symlinks libnspr4.so, libplc4.so, and
libplds4.so both for linking (so that the linker flags
-lplc4 -lplds4 -lnspr4 work) and for backward compatibility
with our current sonames.

The challenge is to include these symlinks in our
Netscape-style binary distributions (the mdbinary.jar
files).  I don't know if Red Hat or Sun still produces
them.

I only implemented this for Linux for now.  I can
easily implement this for other platforms.  Note that
the standard sonames for HP-UX and Mac OS X are unique:

HP-UX (with the old .sl suffix): libnspr4.4 (no .sl)
Mac OS X: libnspr4.4.dylib (.4 before .dylib)

Comment 1

[Michael Haubenwallner]

As the MOD_MAJOR_VERSION already is part of the library name via LIBRARY_VERSION, wouldn't it make more sense to use MOD_MINOR_VERSION instead, resulting in libnspr4.so.8 (for nspr-4.8.x).

For HP-UX (hppa): there is no technical reason to omit the ".sl" - in fact, *any* filename will work as the "internal name".

Even for (newer?) AIX it should be possible to implement something like "soname": Create libnspr4.so as "Import File" referring to libnspr4.so.X - although libnspr4.so cannot be dynamically opened then (just libnspr4.so.X). So for backwards binary compatibility this might start with nspr5 only.

Comment 2

[Wan-Teh Chang]

Michael: Thank you for your comment.

The SONAME of a library should contain the library's major version
only because it indicates binary compatibility.  We should not put
the library's minor version or patch level in its SONAME.

Omitting the ".sl" in HP-UX's internal name is just to follow HP-UX
system libraries' convention.  This bug is all about following the
OS's conventions.  Otherwise, I can also say that since any filename
will work as the SONAME, the current SONAME of libnspr4.so, libplc4.so,
libplds4.so is just fine.

Comment 3

[Michael Haubenwallner]

(In reply to comment #2)
> The SONAME of a library should contain the library's major version
> only because it indicates binary compatibility.  We should not put
> the library's minor version or patch level in its SONAME.

Agreed. But isn't the "4" in "nspr4" the major version already?

> Omitting the ".sl" in HP-UX's internal name is just to follow HP-UX
> system libraries' convention.

Actually I don't care filenames: it requires another case to deal with in library name generation, because ia64-hpux uses "libnspr4.so.4".

> This bug is all about following the OS's conventions.

I don't think so: It is nice to follow OS's conventions, but the main point of SONAME is to have a different filename for runtime (with major version) than for linktime (without major version).

Consequently, IFF "nspr4" contains the major version, shouldn't the linkname become just 'nspr' ("libnspr.so") - and the SONAME "libnspr.so.4" - then?

Comment 4

[Wan-Teh Chang]

Yes, the major version "4" is in the current SONAME "libnspr4.so"
already.  So this bug is really a cosmetic issue.  However, it gets
a lot of complaints from people who generate NSPR packages because
they expect an SONAME with a version number after ".so".

(My proposal for the HP-UX internal name "libnspr4.4" is for the
old HP-UX .sl suffix only.  If the .so suffix is used, the internal
name should be "libnspr4.so.4".)

If I could go back in time, I would have named the library libnspr.so
with SONAME libnspr.so.4, exactly as you suggested.

Comment 5

[Michael Haubenwallner]

(In reply to comment #4)
> Yes, the major version "4" is in the current SONAME "libnspr4.so"
> already.  So this bug is really a cosmetic issue.

As long as the major version is used for *linking* too, this bug is *not* just cosmetic IMO. So maybe this bug (or a new one?) should be about "drop the version number from the linkable library name", while keeping the SONAME as is for historical reasons.
So when there is "libnspr.so" for *linking*, the SONAME being "libnspr4.so" or "libnspr.so.4" is just cosmetic indeed.

Comment 6

[Wan-Teh Chang]

No, we can't change the name for linking to "libnspr.so" because that'll
break the build systems of all the NSPR-based products that hardcode
-lplds4 -lplc4 -lnspr4 in their makefiles.

A good way to think about the current situation is that "nspr4" is the
name of the library, "4" is the major version of the library, and new
major versions of the library will never be released (because there's
no compelling reason to break backward compatibility).

Comment 7

[Michael Haubenwallner]

AFAICT, the majority of the platforms allows to link against the SONAME too, so having "libnspr.so" for linking could be an addition instead of a change.
Wouldn't this allow for both compatibility with '-lnspr4' as well as using the different linkname '-lnspr' when necessary?

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.