Use standard shared library soname libnspr4.so.4.

RESOLVED INACTIVE

Status

NSPR
NSPR
RESOLVED INACTIVE
10 years ago
2 days ago

People

(Reporter: Wan-Teh Chang, Assigned: Wan-Teh Chang)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

10 years ago
Created attachment 336125 [details] [diff] [review]
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)
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.
(Assignee)

Comment 2

8 years ago
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.
(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?
(Assignee)

Comment 4

8 years ago
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.
(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.
(Assignee)

Comment 6

8 years ago
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).
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?

Updated

3 years ago
Depends on: 1142929

Comment 8

2 days ago
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: ASSIGNED → RESOLVED
Last Resolved: 2 days ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.