| Message ID | mhng-ea008aed-2764-44a7-8bcb-f0512da9cdff@palmer-si-x1c4 |
|---|---|
| State | Dropped |
| Headers |
Received: (qmail 82027 invoked by alias); 18 Mar 2019 11:06:25 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <libc-alpha.sourceware.org> List-Unsubscribe: <mailto:libc-alpha-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 82009 invoked by uid 89); 18 Mar 2019 11:06:25 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.1 spammy=HX-Spam-Relays-External:209.85.210.194, Unfortunately, ultimate, H*RU:209.85.210.194 X-HELO: mail-pf1-f194.google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; h=date:subject:in-reply-to:cc:from:to:message-id:mime-version :content-transfer-encoding; bh=0jP3hDEDSGhZjYpkX6Gm1E3ICU1IMtYGiW92htuQn6E=; b=mvRVNXrkV/34+/pFAu7tPQ3y6yyhHdAjYuluCrx0MjC5fJIa5rTE3PxDgPjS/TT6kz TxoqcfpGZsC+pxw37XZ9SqmdeA7J5NKk0S/GmPFyKAUV7WASkuBElQLCkGd6MYOeUBbl Nli2zRk9MzX6bdQoA0qsOR5UKqf1H/kxQwo50WyDqPt1r2PadaGQCxcYC2GgWhAvKuep 3jPSQL01xmskWDM0v6kIsF6ml08TKBHnxXUlHgRkVHPb/y1ad/h/snvSTLcwv6JKx50E 2N0ewddsACT5tylNQ/RlSsO57zNGSR92YOo7VSmwH4owt5K68IHn4L9qlhcDrrA8pfJi 0nPw== Return-Path: <palmer@sifive.com> Date: Mon, 18 Mar 2019 04:06:20 -0700 (PDT) X-Google-Original-Date: Mon, 18 Mar 2019 04:06:16 PDT (-0700) Subject: Re: [PATCH] Respect CPPFLAGS when generating stdio-lim.h In-Reply-To: <mvm1s34qwsa.fsf@suse.de> CC: libc-alpha@sourceware.org From: Palmer Dabbelt <palmer@sifive.com> To: schwab@suse.de Message-ID: <mhng-ea008aed-2764-44a7-8bcb-f0512da9cdff@palmer-si-x1c4> Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit |
Commit Message
Palmer Dabbelt
March 18, 2019, 11:06 a.m. UTC
On Mon, 18 Mar 2019 03:52:53 PDT (-0700), schwab@suse.de wrote: > On Mär 18 2019, Palmer Dabbelt <palmer@sifive.com> wrote: > >> diff --git a/Makerules b/Makerules >> index 83bdd3a44d0d..a81395b4b62e 100644 >> --- a/Makerules >> +++ b/Makerules >> @@ -1423,7 +1423,7 @@ $(stdio_lim:h=st): $(..)stdio-common/stdio_lim.h.in $(..)Rules \ >> { echo '#include "$(..)posix/bits/posix1_lim.h"'; \ >> } | \ >> $(CC) -E -dM -MD -MP -MF $(@:st=dT) -MT '$(@:st=h) $(@:st=d)' \ >> - $(CPPUNDEFS) $(+includes) -xc - -o $(@:st=hT) >> + $(CPPUNDEFS) $(CPPFLAGS) $(+includes) -xc - -o $(@:st=hT) > > CPPFLAGS already includes $(CPPUNDEFS), so there is no need to use both. Thanks. How does this look? commit d9a1f56c29d7b18930ff6a75f43d52c7c3230546 gpg: Signature made Mon 18 Mar 2019 03:55:36 AM PDT gpg: using RSA key 00CE76D1834960DFCE886DF8EF4CA1502CCBAB41 gpg: issuer "palmer@dabbelt.com" gpg: Good signature from "Palmer Dabbelt <palmer@dabbelt.com>" [ultimate] gpg: aka "Palmer Dabbelt <palmer@sifive.com>" [ultimate] Author: Palmer Dabbelt <palmer@sifive.com> Date: Mon Mar 18 01:24:37 2019 -0700 Respect CPPFLAGS when generating stdio-lim.h The RISC-V port expects that the C compiler provides a handful of definitions that determine the ABI to build for, but some users go through the glibc build process before there is a suitable cross compiler and therefor are compiling with some arbitrary complier. Since we only look at the C preprocessor during the headers build process this should be fine as long as users set CPPFLAGS on their own. Unfortunately, stdio-lim.h isn't respecting CPPFLAGS and instead uses CPPUNDEFS, a variable that isn't standard. This variable is meant to undefine _FORTIFY_SOURCE, and overriding it to also add definitions seems ugly. Instead I think the cleaner fix is to make the stdio-lib.h generation process respect CPPFLAGS like the rest of the build process does. I'm checking via build-many-glibc.py to make sure this builds, but as that never sets CPPFLAGS I don't think it'll find any potential issues. * Makerules (stdio-lim.h): Use $(CPPFLAGS) instead of $(CPPUNDEFS) when invoking $(CC). I'm having some trouble running build-many-glibcs.py, but that's par for the course on my end.
Comments
On Mär 18 2019, Palmer Dabbelt <palmer@sifive.com> wrote: > I'm checking via build-many-glibc.py to make sure this builds, but as > that never sets CPPFLAGS I don't think it'll find any potential issues. Since CPPFLAGS is always set by our makefiles I don't understand this comment. Andreas.
On Mon, 18 Mar 2019 04:47:47 PDT (-0700), schwab@suse.de wrote: > On Mär 18 2019, Palmer Dabbelt <palmer@sifive.com> wrote: > >> I'm checking via build-many-glibc.py to make sure this builds, but as >> that never sets CPPFLAGS I don't think it'll find any potential issues. > > Since CPPFLAGS is always set by our makefiles I don't understand this > comment. My point is that bulid-many-glibcs.py isn't adding any additional CPPFLAGS, so we wouldn't notice anything that might crop up because of how users (who may have set some odd CPPFLAGS) build their glibc. Maybe that's being too paranoid, though?
On Mär 18 2019, Palmer Dabbelt <palmer@sifive.com> wrote: > My point is that bulid-many-glibcs.py isn't adding any additional > CPPFLAGS, so we wouldn't notice anything that might crop up because of how > users (who may have set some odd CPPFLAGS) build their glibc. > > Maybe that's being too paranoid, though? Users setting CPPFLAGS need to be careful anyway. Andreas.
On Mon, 18 Mar 2019 05:11:26 PDT (-0700), schwab@suse.de wrote: > On Mär 18 2019, Palmer Dabbelt <palmer@sifive.com> wrote: > >> My point is that bulid-many-glibcs.py isn't adding any additional >> CPPFLAGS, so we wouldn't notice anything that might crop up because of how >> users (who may have set some odd CPPFLAGS) build their glibc. >> >> Maybe that's being too paranoid, though? > > Users setting CPPFLAGS need to be careful anyway. OK, makes sense. I'll figure out what's going on with build-many-glibcs.py. Thanks!
diff --git a/Makerules b/Makerules index 83bdd3a44d0d..6d138eed613a 100644 --- a/Makerules +++ b/Makerules @@ -1423,7 +1423,7 @@ $(stdio_lim:h=st): $(..)stdio-common/stdio_lim.h.in $(..)Rules \ { echo '#include "$(..)posix/bits/posix1_lim.h"'; \ } | \ $(CC) -E -dM -MD -MP -MF $(@:st=dT) -MT '$(@:st=h) $(@:st=d)' \ - $(CPPUNDEFS) $(+includes) -xc - -o $(@:st=hT) + $(CPPFLAGS) $(+includes) -xc - -o $(@:st=hT) sed $(sed-remove-objpfx) $(sed-remove-dotdot) \ $(@:st=dT) > $(@:st=dt) mv -f $(@:st=dt) $(@:st=d)