Building newlib with -D_FORTIFY_SOURCE=2 fails

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Building newlib with -D_FORTIFY_SOURCE=2 fails

Joakim Nohlgård
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
Reply | Threaded
Open this post in threaded view
|

Re: 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


signature.asc (235 bytes) Download Attachment