511626 - Rename nss.h - in order to avoid conflicts with glibc

Status: RESOLVED INACTIVE

(NSS :: Libraries, defect, P5)

Description

[Kai Engert (:KaiE:)]

It has been proposed to rename include file nss.h that is provided by NSS, in order to avoid conflicts with glibc.

Original bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=501382

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

This will be absolutely unacceptable to all of Sun's products that have used
NSS for the past 13+ years.

Comment 2

[Wan-Teh Chang]

This is a real problem.  We should figure out an alternate
solution that is acceptable.

For example, nss.h could be renamed nss3.h, and we could
provide a nss.h header in a "compat" subdirectory that
simply includes "nss3.h".

Then applications could add -I$(NSS_INCLUDEDIR)/compat to
their compiler command line to avoid modifying the source
files that include "nss.h".

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

*ANY* change to the makefiles or source files of Sun's products that build 
with NSS will be unacceptable.  That is also a real problem.

Comment 4

[Robert Relyea]

It seems to me there is still a way forward, even without the compat directory.

Currently nss does not have a traditional 'make install' target. Our make install installs into the mozilla/dist/XXXX location.

I propose we provide nss3.h which has the current contents of nss.h.
We then provide an nss.h that includes nss3.h.
Both will install in mozilla/dist/XXXX.

NSS source code will change it's includes to only include nss3.h (so would our sample code).

This will not necessitate any change of sun products that build with NSS.
Products (mostly Linux based) which have conflict with name switch service could reframe from shipping nss.h (or ship it in a compat directory.

Since sun products will include NSS form the traditional mozilla/dist packaging, there should be no change to their code or make files.

Mozilla products would also continue to build with no change to their code or make files unless mozilla products need access to name switch service header files. In that case they could rename their use of nss.h to nss3.h and remove nss.h in their make files (change is only needed if they have a conflict).

Linux packages (which are used to adding things like 'compat' could either change to using nss3.h or adding the compat feature) could move nss.h to /usr/include/nss3/compat/nss.h in their nss-devel install packages to avoid conflict with glibc. I believe this the platform that has the most heartache with the conflict.

bob

Comment 5

[Robert Relyea]

NOTE: the 5th paragraph of comment 4 is redundant to the last 3 paragraphs, it probably reads better if you skip it.


bob

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

So, Bob, 
I think your proposal is to have two header files, nss.h and nss3.h
with nss3.h containing everything that is now in nss.h, and nss.h just 
#including nss3.h.  Is that right?

Where would these two files live:
- On linux?  (I'd like to see one solution for ALL flavors of Linux)
- On all systems where nss.h is not a system header?