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.
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?
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.
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?
You need to log in before you can comment on or make changes to this bug.