This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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


>> Now I am checking your patch [1] against Fedora 23 (which I think
>> have
>> the default NSS installation paths).
>> [1]
>>> It is only possible to build GNU libc with Mozilla NSS for
>>> cryptography
>>> by using AT LEAST either of the two following patches:
>>> [1] (fixes
>>> possible conflicts between Mozilla NSS nss.h header file and GNU
>>> libc
>>> nss.h header file)
>>> AND/OR
>>> [2]
>>> (fixes
>>> the GNU libc build system to correctly detect and use Mozilla
>>> NSPR) 
>>> and using the following patch for sanitising the test suite:
>>> [3]
>>> (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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]