Building newlib with -D_FORTIFY_SOURCE=2 fails

[Yaakov Selkowitz]

On 2017-12-12 04:51, Joakim Nohlgård wrote:
> 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.

Which is nonstandard, btw.

> 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)`.

What do you do when building glibc or gcc?

> 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.

I'm not sure where we could put something to force-disable this (along
with -fno-stack-protector to cancel -fstack-protector*) across
newlib/libgloss/cygwin.  OTOH this could simply be considered something
that should be handled at the packaging level.

-- 
Yaakov

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <http://sourceware.org/pipermail/newlib/attachments/20171212/a8b6f9e3/attachment.sig>