Building newlib with -D_FORTIFY_SOURCE=2 fails

[Joakim Nohlgård <joakim dot nohlgard at eistec dot se>]

Dear developers,
Compilation of gets.c, strcpy.c and several others fail when building
newlib with a GCC version which defines _FORTIFY_SOURCE to 2 by
default.
The compilation failure is that the ssp/stdio.h header defines gets,
strcpy etc. as macros which expand to __gets_chk(xxx, __ssp_bos(str)),
this macro will then replace the definition of the function in the C
file as well, causing a syntax error in the compilation.

I realise that my compiler does not use the vanilla settings, but it
is the default configuration for Gentoo based GCC installations, which
have a patch for GCC that defines _FORTIFY_SOURCE as a builtin macro
with the expansion `((defined __OPTIMIZE__ && __OPTIMIZE__ > 0) ? 2 :
0)`.
I run newlib configure with CFLAGS_FOR_TARGET=-U_FORTIFY_SOURCE to let
the build succeed, but I think it would probably be better if newlib
could detect this automatically and disable _FORTIFY_SOURCE for the
actual implementations of these library functions which will be
wrapped by _FORTIFY_SOURCE. I guess these problems began when the SSP
headers were merged some months ago, because I did not have any build
problems before using the same installed compiler.

So if anyone has the same problem, the workaround for now is to use
CFLAGS_FOR_TARGET=-U_FORTIFY_SOURCE when running configure.

Best regards,
Joakim Nohlgård