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

[Guido Trentalancia <guido at trentalancia dot net>]

Hello again.

On Tue, 31/05/2016 at 16.05 -0300, Adhemerval Zanella wrote:
> 
> On 31/05/2016 14:00, Guido Trentalancia wrote:
> > Hello Carlos.
> > 
> > On Tue, 31/05/2016 at 11.50 -0400, Carlos O'Donell wrote:
> > > On 05/31/2016 11:33 AM, Guido Trentalancia wrote:
> > > > 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).
> > > 
> > > Adhemerval or myself can write the ChangeLog for you as a first
> > > time
> > > contributor.
> > > 
> > > The real issue is that I don't think your patch are quite correct
> > > or we haven't found the real cause of the failure.
> > > 
> > > On Fedora we use --enable-nss-crypt for all of our builds and see
> > > no problems.
> > > 
> > > You add nss3/nspr include directories to CFLAGS, which should not
> > > be needed.
> > 
> > It is needed because the configure test program uses hasht.h
> > (and nsslowhash.h) from the Mozilla NSS library which has the
> > following
> > include:
> > 
> > #include "prtypes.h"
> > 
> > That is why, unless Mozilla NSPR changes the above to:
> > 
> > #include <nspr/prtypes.h>
> > 
> > the configure test program from GNU libc fails to compile.
> > 
> > I bet in Fedora you have patched with sed the Mozilla NSS header
> > files
> > so that they include <nspr/prtypes.h> instead of "prtypes.h"...?
> 
> Nops, the distro I am using does not have this change, all the
> headers
> uses plain '#include "prtypes.h"'. 

So, you either need the patch posted with the following message
subject:

[PATCH v3] When using the Mozilla NSS library for cryptography, include
the NSPR header files

or otherwise, you need the patch posted with this message subject in
conjunction with:

CPPFLAGS="-I/path_to_your_NSS_header_files -I/path_to_your_NSPR_header_files"

The two above mentioned patches are compatible with each other, so you
can also use both (without the need for setting CPPFLAGS).

> The only deviation is libfreebl3.so is
> not installed in the expected folder.
> 
> However I does not prevent to correctly configure it if I instruct
> the
> linekr flags to check on correct folder for nss plugins.
> 
> I think this patch is wrong because even when nss.h is presented on
> the
> system, GLIBC include sysdep directive will use GLIBC own nss.h
> header.

I have tested the latest versions of all patches submitted and they are
correct because they fix the problem and prevent it from happening.

> Building using with --enable-nss-crypt with the patch to fix the npsr
> include and add the linker command to find libfreebl3.so in my
> system,
> the md5-crypt.c shows:
> 
> ---
> typedef int PRBool;
> # 1 "/usr/include/nss/hasht.h" 1
> 
> 
> 
> 
> 
> #define _HASHT_H_Â
> 
> # 1 "/usr/include/nspr/prtypes.h" 1
> # 21 "/usr/include/nspr/prtypes.h"
> #define prtypes_h___Â
> 
> 
> 
> 
> # 1 "/usr/include/nspr/prcpucfg.h" 1
> # 12 "/usr/include/nspr/prcpucfg.h"
> #define nspr_cpucfg___Â
> ---
> 
> And my hasht.h has:
> 
> Â 5 #ifndef _HASHT_H_
> Â 6 #define _HASHT_H_
> Â 7Â
> Â 8 #include "prtypes.h"
> 
> So I do not think this is the correct fix.

What makes you think that it is not the correct fix ? You have first to
overcome the problems with the file locations, as introduced by your
distribution, not being compliant with FHS, then everything will work.

As already explained, the three patches fixes slightly different things
and they have been designed to work together:

[1] https://sourceware.org/bugzilla/attachment.cgi?id=9302 (fixes
possible conflicts between Mozilla NSS nss.h header file and GNU libc
nss.h header file)

[2] https://sourceware.org/ml/libc-alpha/2016-05/msg00738.html (fixes
the GNU libc build system to correctly detect and use Mozilla NSPR)

[3] https://sourceware.org/ml/libc-alpha/2016-05/msg00729.html (fixes
the GNU libc test system to prevent false positives related to the use
of the Mozilla NSPR header files)

[...]

> > It might be a bug with the Mozilla NSS header files, however
> > applying
> > the patches to GNU libc won't hurt I suppose. When using the latest
> > versions of the three patches, I get no new test failures and in
> > particular, no test failures within the nss or crypt components.

[...]

Best regards,

Guido Trentalancia