From patchwork Tue May 31 19:41:39 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Adhemerval Zanella Netto X-Patchwork-Id: 68952 Delivered-To: patch@linaro.org Received: by 10.140.92.199 with SMTP id b65csp2149526qge; Tue, 31 May 2016 12:42:06 -0700 (PDT) X-Received: by 10.98.152.142 with SMTP id d14mr58237534pfk.105.1464723725723; Tue, 31 May 2016 12:42:05 -0700 (PDT) Return-Path: Received: from sourceware.org (server1.sourceware.org. [209.132.180.131]) by mx.google.com with ESMTPS id vy4si5954992pab.231.2016.05.31.12.42.05 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 May 2016 12:42:05 -0700 (PDT) Received-SPF: pass (google.com: domain of libc-alpha-return-70066-patch=linaro.org@sourceware.org designates 209.132.180.131 as permitted sender) client-ip=209.132.180.131; Authentication-Results: mx.google.com; dkim=pass header.i=@sourceware.org; spf=pass (google.com: domain of libc-alpha-return-70066-patch=linaro.org@sourceware.org designates 209.132.180.131 as permitted sender) smtp.mailfrom=libc-alpha-return-70066-patch=linaro.org@sourceware.org; dmarc=fail (p=NONE dis=NONE) header.from=linaro.org DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:subject:to:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; q=dns; s=default; b=PaGehWkPozhHBXUn 5yeWiqkCYlV9mqVTRk2RSPKpJB+8uAYdyYqenIvkNoJDPTEynC3CjIFrYXBGCwBg P5TPbQMwSQKVwNLztSp9rPzuqaSKAFBGb4X/le0LSPzE+NnDYK7EjUxP+u6Weove ZGlx7tMl6eP9gWo1FyOQ9NfL5Fw= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:subject:to:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; s=default; bh=L7EYK/RMOv+EmvzakQlaPa VnZgs=; b=QAPrbDZGw1qw8IIslZWLqSZAC1JLa5oMUYYjQCuSFqGKk6V9qUzEqA 5J55Miwf2Qd5tGJ8q3pAJaXCDoadyhjdV2uwJBuyRx49iYalqpYkseOqSrNWBu03 ySKAMCbxxX3++a895aiSHh6PcBHEu0R51M8WXaTDu/cTbTYFdqbD0= Received: (qmail 100716 invoked by alias); 31 May 2016 19:41:55 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 100705 invoked by uid 89); 31 May 2016 19:41:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.2 spammy=overcome, 1605, compliant, sk:path_to X-HELO: mail-yw0-f171.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=LjhybKln83QFVs5x8SHqiLucz9vz1gwt3RUx4QGxWY8=; b=E4pMGyuep3JUQ+EA0SaXyAwEFXqJ5a5cOe5LQebG7yCr6oWH4Q1tCYme2F52j7oKtF dWEEST+l8P47AIUrAF1WYtXaMsHu4BlsaghXEVIqisM5G+14nJS9UZbJKHrEYkQ7uyAE YfCriJPRzx+YeHlAQeR8Qz5odvNq4dOrhMJSQ2t3uIPTduyAmpdWZutQPrSKDOGIfW5W vt2EQVf1Uz+FhF3rDGLYb6aK+RKIlT/XyMS1MVfRsTijzCPx+1IHbqvMvwXIEUdVnqix buLMClOHkpVw6ZDOEjyXr2fpA42qBYfv+Q8jjQoRYchv4PVRAAVZTYeWULCjp6WG7L9V 3jCQ== X-Gm-Message-State: ALyK8tKM2bgjLUfU1YLznrC/LodAfaFKBQCwxzBr7utu9CwsAcHr66Srwq2km9CvRWzALtU4 X-Received: by 10.129.154.204 with SMTP id r195mr20002142ywg.119.1464723702981; Tue, 31 May 2016 12:41:42 -0700 (PDT) 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 To: Guido Trentalancia , Carlos O'Donell , libc-alpha@sourceware.org References: <1464635653.24965.5.camel@trentalancia.net> <1464700854.24965.21.camel@trentalancia.net> <574DA91E.9040508@linaro.org> <1464708782.2379.12.camel@trentalancia.net> <574DB2E3.4020405@redhat.com> <1464714039.2379.30.camel@trentalancia.net> <574DE05C.1010803@linaro.org> <1464722661.2379.61.camel@trentalancia.net> From: Adhemerval Zanella Message-ID: <574DE8F3.3090306@linaro.org> Date: Tue, 31 May 2016 16:41:39 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <1464722661.2379.61.camel@trentalancia.net> 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 >>> >>> 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 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. > >> Building using with --enable-nss-crypt with the patch to fix the npsr >> include and add the linker command to find libfreebl3.so in my >> system, >> the md5-crypt.c shows: >> >> --- >> typedef int PRBool; >> # 1 "/usr/include/nss/hasht.h" 1 >> >> >> >> >> >> #define _HASHT_H_ >> >> # 1 "/usr/include/nspr/prtypes.h" 1 >> # 21 "/usr/include/nspr/prtypes.h" >> #define prtypes_h___ >> >> >> >> >> # 1 "/usr/include/nspr/prcpucfg.h" 1 >> # 12 "/usr/include/nspr/prcpucfg.h" >> #define nspr_cpucfg___ >> --- >> >> And my hasht.h has: >> >> 5 #ifndef _HASHT_H_ >> 6 #define _HASHT_H_ >> 7 >> 8 #include "prtypes.h" >> >> So I do not think this is the correct fix. > > What makes you think that it is not the correct fix ? You have first to > overcome the problems with the file locations, as introduced by your > distribution, not being compliant with FHS, then everything will work. > Because the file location only interfere with *linking* phase, where this patch changes a lot of *compilation phase*. The snipped of pre-procesor shows that only one the configure patch you sent, GLIBC can get the correct nss.h header and there is no conflict in the build. > As already explained, the three patches fixes slightly different things > and they have been designed to work together: > > [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) interfering with own GLIBC build since glibc set its own patch as priority one in the include list. > > [2] https://sourceware.org/ml/libc-alpha/2016-05/msg00738.html (fixes > the GNU libc build system to correctly detect and use Mozilla NSPR) > > [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) > > [...] > >>> It might be a bug with the Mozilla NSS header files, however >>> applying >>> the patches to GNU libc won't hurt I suppose. When using the latest >>> versions of the three patches, I get no new test failures and in >>> particular, no test failures within the nss or crypt components. > > [...] > > Best regards, > > Guido Trentalancia > --- 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 +#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 @@ . */ #include -#include +#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