From patchwork Mon Mar 18 09:20:58 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Palmer Dabbelt X-Patchwork-Id: 31877 Received: (qmail 23458 invoked by alias); 18 Mar 2019 09:22:00 -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 23130 invoked by uid 89); 18 Mar 2019 09:22:00 -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=cleaner, HX-Received:d84b, H*r:sk:mail-pg, HX-Spam-Relays-External:sk:mail-pg X-HELO: mail-pg1-f176.google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; h=subject:date:message-id:mime-version:content-transfer-encoding:cc :from:to; bh=FfOBwAwznmqiw4j0E8uChyXb5sfrUqhXza1pdhtvGKs=; b=GUjYvTr8eKmJFKbNS+u3AkvYOkGHp9Zfu8J+k1ayJjsemEFPbXcCrd3kes1HKt1RLj YVeKscEy0e+/+W1ttY3ufzU4hNHnwAsdtxseRVwpTfOPqBjACKq4lmmUmWnXPWHQEgdL WHjvkAkLlduW2lg4jgIJR/wsdBmAJ/jYvmneStjWyDGyFGlI0tlKnM8AqcOk7SgaJv/K L42hsOn+FYujzxmVCilXgR1TwjJJJLBLiCq7OAToaBaWajgDVPGGDoabDPGmartnoSgN UoP0cXRN+Px7zWjTU7j3SDTrHVJOkzrlYi7CTCAdeMgeY4jQ+IgS6LDDQDFzFHnpM8Fx ExJg== Return-Path: Subject: [PATCH] Respect CPPFLAGS when generating stdio-lim.h Date: Mon, 18 Mar 2019 02:20:58 -0700 Message-Id: <20190318092058.5531-1-palmer@sifive.com> MIME-Version: 1.0 Cc: Palmer Dabbelt From: Palmer Dabbelt To: libc-alpha@sourceware.org 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): Add $(CPPFLAGS) to CC invocation. --- Makerules | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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) sed $(sed-remove-objpfx) $(sed-remove-dotdot) \ $(@:st=dT) > $(@:st=dt) mv -f $(@:st=dt) $(@:st=d)