[PATCH alternative] newlib: ignore _FORTIFY_SOURCE when building newlib
Mike Frysinger
vapier@gentoo.org
Tue Nov 9 02:59:06 GMT 2021
Some distros enable _FORTIFY_SOURCE by default which upsets building
newlib which itself implements the logic for this define. For example,
building gets.c fails because the includes set up a gets() macro which
expands in the definition.
Since newlib isn't prepared to build itself with _FORTIFY_SOURCE, and
it's not clear if it's even useful, ignore it when building the code.
This also matches what glibc is doing.
---
NB: This is an alternative approach instead of passing -U_FORTIFY_SOURCE.
I think the -U approach is better, but throwing this up for discussion.
newlib/libc/include/sys/features.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/newlib/libc/include/sys/features.h b/newlib/libc/include/sys/features.h
index 2188071785f6..6b4999e83482 100644
--- a/newlib/libc/include/sys/features.h
+++ b/newlib/libc/include/sys/features.h
@@ -320,7 +320,8 @@ extern "C" {
#endif
#if _FORTIFY_SOURCE > 0 && !defined(__cplusplus) && !defined(__lint__) && \
- (__OPTIMIZE__ > 0 || defined(__clang__)) && __GNUC_PREREQ__(4, 1)
+ (__OPTIMIZE__ > 0 || defined(__clang__)) && __GNUC_PREREQ__(4, 1) && \
+ !defined(_COMPILING_NEWLIB)
# if _FORTIFY_SOURCE > 1
# define __SSP_FORTIFY_LEVEL 2
# else
--
2.33.0
More information about the Newlib
mailing list