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

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