This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
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
- From: Guido Trentalancia <guido at trentalancia dot net>
- To: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, Carlos O'Donell <carlos at redhat dot com>, libc-alpha at sourceware dot org
- Date: Tue, 31 May 2016 22:33:12 +0200
- Subject: 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
- Authentication-results: sourceware.org; auth=none
- References: <1464635653 dot 24965 dot 5 dot camel at trentalancia dot net> <1464700854 dot 24965 dot 21 dot camel at trentalancia dot net> <574DA91E dot 9040508 at linaro dot org> <1464708782 dot 2379 dot 12 dot camel at trentalancia dot net> <574DB2E3 dot 4020405 at redhat dot com> <1464714039 dot 2379 dot 30 dot camel at trentalancia dot net> <574DE05C dot 1010803 at linaro dot org> <1464722661 dot 2379 dot 61 dot camel at trentalancia dot net> <574DE8F3 dot 3090306 at linaro dot org> <1464724652 dot 2379 dot 71 dot camel at trentalancia dot net> <574DF019 dot 5010208 at linaro dot org>
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