[v2,BZ,17956] Fix build failure due to missing definitions from header file nss/nss.h when Mozilla NSS is used for cryptography

  On 31/05/2016 16:24, Guido Trentalancia wrote:
> 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).

Yes I am assuming the configure issue pointed you by your earlier 
message patched.

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

Nops, this does not indicate necessary that the patch is correct. It 
does not even indicate there is an issue since even using a non-default
libnss3 installation with just the initial fix you sent I can build
glibc with NSS enabled.

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


Because the file location only interfere with *linking* phase, where
this patch changes a lot of *compilation phase*. The snipped of pre-procesor
shows that only one the configure patch you sent, GLIBC can get the
correct nss.h header and there is no conflict in the build.


> 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)

interfering with own GLIBC build since glibc set its own patch as priority
one in the include list.

> 
> [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
>
  

On Tue, 31/05/2016 at 16.41 -0300, Adhemerval Zanella wrote:
> 
> On 31/05/2016 16:24, Guido Trentalancia wrote:
> > 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).
> 
> Yes I am assuming the configure issue pointed you by your earlier 
> message patched.
> 
> > 
> > > 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.
> 
> Nops, this does not indicate necessary that the patch is correct. It 
> does not even indicate there is an issue since even using a non-
> default
> libnss3 installation with just the initial fix you sent I can build
> glibc with NSS enabled.

Of course, testing the patch, verifying that it solves the problem
reported and verifying that it does not introduce problems with the
existing code implies that the patch is correct ! Are you joking or
what ?

It is only possible to build GNU libc with Mozilla NSS for cryptography
by using AT LEAST either of the two following patches:

[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)

AND/OR

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

and using the following patch for sanitising the test suite:

[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)

Now, at the request of Carlos O'Donell, [2] and [3] have been merged.

Unfortunately, I do not have so much time available to circle around
the same issues indefinitely. Carlos asked me to understand whether or
not you have sorted the problems with building GNU libc with Mozilla
NSS enabled.

I assume your problems were due to non-compliance with FHS. Can you
confirm ? Are you now able to use the patches and can you confirm that
everything works fine ?

I have carried out extensive testing and everything works fine.

Best regards,

Guido Trentalancia
  

On 31/05/2016 16:57, Guido Trentalancia wrote:
> On Tue, 31/05/2016 at 16.41 -0300, Adhemerval Zanella wrote:
>>
>> On 31/05/2016 16:24, Guido Trentalancia wrote:
>>> 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).
>>
>> Yes I am assuming the configure issue pointed you by your earlier 
>> message patched.
>>
>>>
>>>> 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.
>>
>> Nops, this does not indicate necessary that the patch is correct. It 
>> does not even indicate there is an issue since even using a non-
>> default
>> libnss3 installation with just the initial fix you sent I can build
>> glibc with NSS enabled.
> 
> Of course, testing the patch, verifying that it solves the problem
> reported and verifying that it does not introduce problems with the
> existing code implies that the patch is correct ! Are you joking or
> what ?
> 

Because this problem you are describing does not make sense to me.  I will
recapitulate:

1. I am using your v4 patch [1] that fixes the *configure* which check if
   libnss can be used or not.  This patch seems correct and fixes the
   configure error I am seeing.

2. Now, the system I am using install the libfreebl3 on a non-standard
   system path.  I have multiple ways to 'fix' on my system and the
   way I am using is adding a ad hoc patch to add both -L on both
   configure.ac and crypto/Makefile.  It has nothing to do your patch
   and only fixes a issue in my side.

3. Now, with 1. and 2. fixed I can build GLIBC without any more patches,
   so the issue your are describing and trying to fix *in this thread*
   does not make sense to me.  That's why I think *this* patch is not 
   correct.

Now I am checking your patch [1] against Fedora 23 (which I think have
the default NSS installation paths).

[1] https://sourceware.org/ml/libc-alpha/2016-05/msg00779.html


> It is only possible to build GNU libc with Mozilla NSS for cryptography
> by using AT LEAST either of the two following patches:
> 
> [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)
> 
> AND/OR
> 
> [2] https://sourceware.org/ml/libc-alpha/2016-05/msg00738.html (fixes
> the GNU libc build system to correctly detect and use Mozilla NSPR) 
> 
> and using the following patch for sanitising the test suite:
> 
> [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)
> 
> Now, at the request of Carlos O'Donell, [2] and [3] have been merged.
> 
> Unfortunately, I do not have so much time available to circle around
> the same issues indefinitely. Carlos asked me to understand whether or
> not you have sorted the problems with building GNU libc with Mozilla
> NSS enabled.
> 
> I assume your problems were due to non-compliance with FHS. Can you
> confirm ? Are you now able to use the patches and can you confirm that
> everything works fine ?
> 
> I have carried out extensive testing and everything works fine.
> 
> Best regards,
> 
> Guido Trentalancia
>
  

Hello Adhemerval.

On Tue, 31/05/2016 at 17.12 -0300, Adhemerval Zanella wrote:

[...]

> > Of course, testing the patch, verifying that it solves the problem
> > reported and verifying that it does not introduce problems with the
> > existing code implies that the patch is correct ! Are you joking or
> > what ?
> > 
> 
> Because this problem you are describing does not make sense to me.  I
> will
> recapitulate:
> 
> 1. I am using your v4 patch [1] that fixes the *configure* which
> check if
>    libnss can be used or not.  This patch seems correct and fixes the
>    configure error I am seeing.

So, one of the two patches works as expected. Good.

> 2. Now, the system I am using install the libfreebl3 on a non-
> standard
>    system path.  I have multiple ways to 'fix' on my system and the
>    way I am using is adding a ad hoc patch to add both -L on both
>    configure.ac and crypto/Makefile.  It has nothing to do your patch
>    and only fixes a issue in my side.

My advice is to not modify the configure script and/or the Makefile
manually in that way. It's much better to play with LDFLAGS, if
possible and I bet it is indeed possible in this case...

> 3. Now, with 1. and 2. fixed I can build GLIBC without any more
> patches,
>    so the issue your are describing and trying to fix *in this
> thread*
>    does not make sense to me.  That's why I think *this* patch is
> not 
>    correct.

I have already replied to this !

Try adding:

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

It is perfectly licit to do so and some people might actually do that
when configuring external libraries such as Mozilla NSS, for example,
because they do not know how the configure script is designed.

If you tried the above, you now understand the need for that third (now
second) patch... It optimises the way the preprocessor picks up the
local header files, given that there is a conflict between the two
libraries (both have a subdirectory named "nss" and both have an header
file named "nss.h").

Hope this clarifies the matter now.

However, Carlos suggested not to use this latter patch, by saying that
it introduces "maintenance costs". I don't like it, but I still
recommend it given the naming conflict. It's up to you to decide...

> Now I am checking your patch [1] against Fedora 23 (which I think
> have
> the default NSS installation paths).
> 
> [1] https://sourceware.org/ml/libc-alpha/2016-05/msg00779.html
> 
> 
> > It is only possible to build GNU libc with Mozilla NSS for
> > cryptography
> > by using AT LEAST either of the two following patches:
> > 
> > [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)
> > 
> > AND/OR
> > 
> > [2] https://sourceware.org/ml/libc-alpha/2016-05/msg00738.html
> > (fixes
> > the GNU libc build system to correctly detect and use Mozilla
> > NSPR) 
> > 
> > and using the following patch for sanitising the test suite:
> > 
> > [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)
> > 
> > Now, at the request of Carlos O'Donell, [2] and [3] have been
> > merged.
> > 
> > Unfortunately, I do not have so much time available to circle
> > around
> > the same issues indefinitely. Carlos asked me to understand whether
> > or
> > not you have sorted the problems with building GNU libc with
> > Mozilla
> > NSS enabled.
> > 
> > I assume your problems were due to non-compliance with FHS. Can you
> > confirm ? Are you now able to use the patches and can you confirm
> > that
> > everything works fine ?
> > 
> > I have carried out extensive testing and everything works fine.
> > 
> > Best regards,
> > 
> > Guido Trentalancia

Is there anything else that needs to be done in terms of the patches
before we can close the issue ?

Best regards,

Guido Trentalancia
  

Hello Adhemerval.

On Tue, 31/05/2016 at 17.12 -0300, Adhemerval Zanella wrote:

[...]

> > Of course, testing the patch, verifying that it solves the problem
> > reported and verifying that it does not introduce problems with the
> > existing code implies that the patch is correct ! Are you joking or
> > what ?
> > 
> 
> Because this problem you are describing does not make sense to me.  I
> will
> recapitulate:
> 
> 1. I am using your v4 patch [1] that fixes the *configure* which
> check if
>    libnss can be used or not.  This patch seems correct and fixes the
>    configure error I am seeing.

So, one of the two patches works as expected. Good.

> 2. Now, the system I am using install the libfreebl3 on a non-
> standard
>    system path.  I have multiple ways to 'fix' on my system and the
>    way I am using is adding a ad hoc patch to add both -L on both
>    configure.ac and crypto/Makefile.  It has nothing to do your patch
>    and only fixes a issue in my side.

My advice is to not modify the configure script and/or the Makefile manually in
that way. It's much better to play with LDFLAGS, if possible and I bet it is
indeed possible in this case...

> 3. Now, with 1. and 2. fixed I can build GLIBC without any more
> patches,
>    so the issue your are describing and trying to fix *in this
> thread*
>    does not make sense to me.  That's why I think *this* patch is
> not 
>    correct.

I have already replied to this !

Try adding:

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

It is perfectly licit to do so and some people might actually do that when
configuring external libraries such as Mozilla NSS, for example, because they do
not know how the configure script is designed.

If you tried the above, you now understand the need for that third (now second)
patch... It optimises the way the preprocessor picks up the local header files,
given that there is a conflict between the two libraries (both have a
subdirectory named "nss" and both have an header file named "nss.h").

Hope this clarifies the matter now.

However, Carlos suggested not to use this latter patch, by claiming that it
introduces "maintenance costs". I don't like it, but I still recommend it given
the naming conflict. It's up to you to decide...

> Now I am checking your patch [1] against Fedora 23 (which I think
> have
> the default NSS installation paths).
> 
> [1] https://sourceware.org/ml/libc-alpha/2016-05/msg00779.html
> 
> 
> > It is only possible to build GNU libc with Mozilla NSS for
> > cryptography
> > by using AT LEAST either of the two following patches:
> > 
> > [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)
> > 
> > AND/OR
> > 
> > [2] https://sourceware.org/ml/libc-alpha/2016-05/msg00738.html
> > (fixes
> > the GNU libc build system to correctly detect and use Mozilla
> > NSPR) 
> > 
> > and using the following patch for sanitising the test suite:
> > 
> > [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)
> > 
> > Now, at the request of Carlos O'Donell, [2] and [3] have been
> > merged.
> > 
> > Unfortunately, I do not have so much time available to circle
> > around
> > the same issues indefinitely. Carlos asked me to understand whether
> > or
> > not you have sorted the problems with building GNU libc with
> > Mozilla
> > NSS enabled.
> > 
> > I assume your problems were due to non-compliance with FHS. Can you
> > confirm ? Are you now able to use the patches and can you confirm
> > that
> > everything works fine ?
> > 
> > I have carried out extensive testing and everything works fine.
> > 
> > Best regards,
> > 
> > Guido Trentalancia

Is there anything else that needs to be done in terms of the patches before we
can close the issue ?

Best regards,

Guido Trentalancia
  

On 31/05/2016 17:39, guido guido wrote:
> Hello Adhemerval.
> 
> On Tue, 31/05/2016 at 17.12 -0300, Adhemerval Zanella wrote:
> 
> [...]
> 
>>> Of course, testing the patch, verifying that it solves the problem
>>> reported and verifying that it does not introduce problems with the
>>> existing code implies that the patch is correct ! Are you joking or
>>> what ?
>>>
>>
>> Because this problem you are describing does not make sense to me.  I
>> will
>> recapitulate:
>>
>> 1. I am using your v4 patch [1] that fixes the *configure* which
>> check if
>>    libnss can be used or not.  This patch seems correct and fixes the
>>    configure error I am seeing.
> 
> So, one of the two patches works as expected. Good.
> 
>> 2. Now, the system I am using install the libfreebl3 on a non-
>> standard
>>    system path.  I have multiple ways to 'fix' on my system and the
>>    way I am using is adding a ad hoc patch to add both -L on both
>>    configure.ac and crypto/Makefile.  It has nothing to do your patch
>>    and only fixes a issue in my side.
> 
> My advice is to not modify the configure script and/or the Makefile manually in
> that way. It's much better to play with LDFLAGS, if possible and I bet it is
> indeed possible in this case...

Nops because crypto/Makefile does not use configure LDFLAGS flags.  
You need either change how GLIBC builds libcrypto.so (the  way I did)
or change the system to way GLIBC expect to find the library.

> 
>> 3. Now, with 1. and 2. fixed I can build GLIBC without any more
>> patches,
>>    so the issue your are describing and trying to fix *in this
>> thread*
>>    does not make sense to me.  That's why I think *this* patch is
>> not 
>>    correct.
> 
> I have already replied to this !
> 
> Try adding:
> 
> CPPFLAGS="-I/path_to_your_NSS_header_files -I/path_to_your_NSPR_header_files"
> 
> It is perfectly licit to do so and some people might actually do that when
> configuring external libraries such as Mozilla NSS, for example, because they do
> not know how the configure script is designed.
> 
> If you tried the above, you now understand the need for that third (now second)
> patch... It optimises the way the preprocessor picks up the local header files,
> given that there is a conflict between the two libraries (both have a
> subdirectory named "nss" and both have an header file named "nss.h").
> 
> Hope this clarifies the matter now.
> 
> However, Carlos suggested not to use this latter patch, by claiming that it
> introduces "maintenance costs". I don't like it, but I still recommend it given
> the naming conflict. It's up to you to decide...

I am not using the CPPFLAGS because with just one patch [1] I can build
GLIBC with --enable-nss-crypt.  There is *no* need for this patch
besides the configure one you sent.  

The problem seems that you are trying to build using a nss/nspr installed
in a non-default path, which is *not* supported currently. The currently
way is to use nss-config/nspr-config to get the include dir, *not* by
providing them using CPPFLAGS/CFLAGS.

Again, this patch is not the way to enable the build using a non-default
nss/nspr installation.  In fact I am not sure if it is worth to even 
enable or support this configure option.

Btw, I can build GLIBC --enable-nss-crypt on Fedora 23 without any
patch.  I presume it is due some distro changes, but your initial
configure patch also does not break it (which is good).

[1] https://sourceware.org/ml/libc-alpha/2016-05/msg00779.html

> 
>> Now I am checking your patch [1] against Fedora 23 (which I think
>> have
>> the default NSS installation paths).
>>
>> [1] https://sourceware.org/ml/libc-alpha/2016-05/msg00779.html
>>
>>
>>> It is only possible to build GNU libc with Mozilla NSS for
>>> cryptography
>>> by using AT LEAST either of the two following patches:
>>>
>>> [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)
>>>
>>> AND/OR
>>>
>>> [2] https://sourceware.org/ml/libc-alpha/2016-05/msg00738.html
>>> (fixes
>>> the GNU libc build system to correctly detect and use Mozilla
>>> NSPR) 
>>>
>>> and using the following patch for sanitising the test suite:
>>>
>>> [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)
>>>
>>> Now, at the request of Carlos O'Donell, [2] and [3] have been
>>> merged.
>>>
>>> Unfortunately, I do not have so much time available to circle
>>> around
>>> the same issues indefinitely. Carlos asked me to understand whether
>>> or
>>> not you have sorted the problems with building GNU libc with
>>> Mozilla
>>> NSS enabled.
>>>
>>> I assume your problems were due to non-compliance with FHS. Can you
>>> confirm ? Are you now able to use the patches and can you confirm
>>> that
>>> everything works fine ?
>>>
>>> I have carried out extensive testing and everything works fine.
>>>
>>> Best regards,
>>>
>>> Guido Trentalancia
> 
> Is there anything else that needs to be done in terms of the patches before we
> can close the issue ?

Again, I do not think this patch is correct.
  

On 05/31/2016 04:57 PM, Adhemerval Zanella wrote:
> Btw, I can build GLIBC --enable-nss-crypt on Fedora 23 without any
> patch.  I presume it is due some distro changes, but your initial
> configure patch also does not break it (which is good).

I'm curious why this doesn't break on F23.

Perhaps it has to do with packaging of NSS in Fedora?
  

Hello Adhemerval.

On Tue, 31/05/2016 at 17.57 -0300, Adhemerval Zanella wrote:

[...]

> Btw, I can build GLIBC --enable-nss-crypt on Fedora 23 without any
> patch.  I presume it is due some distro changes, but your initial
> configure patch also does not break it (which is good).

Yes, it must be due to distribution patches, most probably patches to those
Mozilla NSS header files that use the Mozilla NSPR header files.

For example, as already pointed out:

#include "prtypes.h" ===> #include <nspr/prtypes.h>

I suppose the Mozilla NSS (and NSPR) library hasn't been initially designed to
be used as a standalone library.

> Again, I do not think this patch is correct.

If you think this patch is not correct, simply use the other one then.

Best regards,

Guido Trentalancia