This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH v2] [BZ 17956] Fix build failure due to missing definitions from header file nss/nss.h when Mozilla NSS is used for cryptography
- From: Guido Trentalancia <guido at trentalancia dot net>
- To: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, libc-alpha at sourceware dot org
- Date: Tue, 31 May 2016 17:33:02 +0200
- Subject: Re: [PATCH v2] [BZ 17956] Fix build failure due to missing definitions from header file nss/nss.h when Mozilla NSS is used for cryptography
- Authentication-results: sourceware.org; auth=none
- References: <1464635653 dot 24965 dot 5 dot camel at trentalancia dot net> <1464700854 dot 24965 dot 21 dot camel at trentalancia dot net> <574DA91E dot 9040508 at linaro dot org>
thanks for getting back about this patch and the other issues with the
header inclusion system.
Il giorno mar, 31/05/2016 alle 12.09 -0300, Adhemerval Zanella ha
> On 31/05/2016 10:20, Guido Trentalancia wrote:
> > A build failure might occur when glibc is configured with the
> > --enable-nss-crypt option in order to use Mozilla NSS library for
> > cryptography.
> > Such failure is due to conflicting "nss.h" header files: one from
> > GNU
> > glibc and the other from the Mozilla NSS library (usually located
> > at
> > /usr/include/nss3/nss.h).
> > For example, a build configuration that leads to the occurrence of
> > this
> > bug includes passing the Mozilla NSS library headers full path to
> > the
> > preprocessor using CPPFLAGS.
> > This patch aims to fix such build failure (BZ 17956) by helping the
> > preprocessor pick the right (local) "nss.h" header file during
> > compilation.
> > This new version includes amendments to both source and test files
> > (in a
> > unique patch instead of two separate patches).
> This is missing a proper ChangeLog 
I can write one if needed. However, the patch is trivial (it mostly
just sources nss.h differently using a relative path, a not much more).
> Besides that I am not following this patch.ÂÂThe only function
> defined in
> nss/nss.h is __nss_configure_lookup along with some other internal
> (NSS_STATUS_*).ÂÂThe ABI from libnss3 nss.h file is completely
> I am not seeing how we can just replace its inclusion.
Wherever you see <nss/nss.h> or "nss.h" or similar within GNU libc it
is meant nss.h from GNU libc and not from libnss3.
However under some circumstances it might happen that the latter is
sourced instead of the GNU libc, causing a build failure.
> My understanding is trying to building using configured provided
> defies the proper configure check plus makefile rules that uses
> provides nss-config and nspr-config commands to get the very include
> and library directories (and as you pointed out in a earlier message
> it seems also broken ).
 is another patch that is highly recommended, although it won't
completely solve BZ 17956, it might only prevent it from happening.
To make the inclusion of nss.h from GNU libc robust this patch is
necessary even when  has been applied.
> So I think the proper way to re-enable external nss build is first
> the configure checks and instead of passing the external flags
> CPPFLAGS, to make sure the intended nss-config/nspr-config are on
> for both configure check and makefile rule generation to get the
As already explained, it is highly recommended that  is applied
([PATCH v2] When using the Mozilla NSS library for cryptography,
include the NSPR header files).
Then this patch should be applied to make the build system completely
robust, even against modified CPPFLAGS.
Finally, a third patch should be applied to prevent false positives
(FAIL) in one test:Â[PATCH v2] Ignore nspr headers directory when
checking local headers
I recommend to apply all the three patches as soon as possible so that
the build and test systems are sane and robust when using the Mozilla
NSS library for cryptography !
Please let me know if the ChangeLog is required for the first two
patches and I will be glad to prepare one (what has been changed is
trivial and explained in the header of each patch).
>  https://sourceware.org/ml/libc-alpha/2016-05/msg00746.html