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

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

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"'. 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.
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.

> 
>> Your configure fails if you don't, and *that* is the key problem
>> we should be looking at.
>>
>> The NSS headers are derived from calling, as they should:
>> nss-config --includedir
>> And that is used everywhere it is needed.
>>
>> So the fault appears to be in your nss-config?
> 
> Nope.
> 
>> What does your failing config.log show?
> 
> It shows that the configure test program does not compile because it
> cannot source the required Mozilla NSPR header file.
> 
>> What does `nss-config --includedir` print on your system?
> 
> It prints the correct location of Mozilla NSS header files (but
> not those of Mozilla NSPR header files which are sources without the
> correct path).
> 
> 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.
> 
> So, what should we do ? If you are willing to accept the changes as a safety precaution even though it might be a bug in the Mozilla NSS header files, then I can write the ChangeLog, otherwise it doesn't matter.
> 
> Best regards,
> 
> Guido Trentalancia
>