[PATCH alternative] newlib: ignore _FORTIFY_SOURCE when building newlib

[Corinna Vinschen]

On Nov  8 21:59, Mike Frysinger wrote:
> 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

I like this one more.  Most people have no problems to look into
source, but many shy away from the convoluted build system.


Thanks,
Corinna