| Message ID | 574DE8F3.3090306@linaro.org |
|---|---|
| State | New |
| Headers | show |
On 31/05/2016 16:57, Guido Trentalancia wrote: > 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 ? > 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. 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. 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. 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 >
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.
--- glibc/grp/fgetgrent_r.c 2016-05-30 13:25:35.403697020 +0200 +++ glibc-31052016-0900GMT/grp/fgetgrent_r.c 2016-05-31 10:26:09.912895303 +0200 @@ -33,7 +33,7 @@ struct grent_data {}; #define TRAILING_LIST_MEMBER gr_mem #define TRAILING_LIST_SEPARATOR_P(c) ((c) == ',') -#include <nss/nss_files/files-parse.c> +#include "../nss/nss_files/files-parse.c" These changes does not make any sense, you are either providing a include patch where this files is being conflicting with GLIBC version or it is something very strange with your build system. --- glibc/grp/putgrent.c 2016-05-30 13:25:35.404697023 +0200 +++ glibc-31052016-0900GMT/grp/putgrent.c 2016-05-31 11:32:52.669065354 +0200 @@ -16,7 +16,7 @@ <http://www.gnu.org/licenses/>. */ #include <errno.h> -#include <nss.h> +#include "../include/nss.h" As I explained, even with libnss3 own header on system default include dir (/usr/include or any other defined system include path), I see no way it is