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