This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
[PATCH] Respect CPPFLAGS when generating stdio-lim.h
- From: Palmer Dabbelt <palmer at sifive dot com>
- To: libc-alpha at sourceware dot org
- Cc: Palmer Dabbelt <palmer at sifive dot com>
- Date: Mon, 18 Mar 2019 02:20:58 -0700
- Subject: [PATCH] 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): 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)
--
2.19.2