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 guido <guido at trentalancia dot net>]

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