GCC C++ compiler for powerpc defines _GNU_SOURCE as a built-in

[Sebastian Huber]

For example:

powerpc-rtems6-g++ -E -P -v -dD empty.cc 2>&1 | grep GNU_SOURCE

Yields:

 /opt/rtems/6/libexec/gcc/powerpc-rtems6/10.2.1/cc1plus -E -quiet -v -P -D_GNU_SOURCE -Dmpc750 empty.cc -dD
#define _GNU_SOURCE 1

This is a GCC configuration bug. The reason is that the RTEMS GCC configuration includes gnu-user.h.

[Joel Sherrill]

I agree that this isn't right. We shouldn't be implicitly defining anything that enables extended APIs.

How did you spot this?

[Sebastian Huber]

I noticed this during the tests of the new build system. The powerpc is the only RTEMS target which defines _GNU_SOURCE.

[Chris Johns]

Replying to Joel Sherrill:

How did you spot this?

I have updated rtems-exeinfo to optionally output the full flags used to build an object file.

$ rtems-exeinfo -O --full-flags `find . -name hello.exe`

This is the output from hello.exe for the psim showing a mix of options:

   | wcrtomb.c                         : -mcpu=603e -mcpu=603e -g -O2 -fno-builtin -ffunction-sections -fdata-sections
   | wctomb_r.c                        : -mcpu=603e -mcpu=603e -g -O2 -fno-builtin -ffunction-sections -fdata-sections
   | wkspace.c                         : -mcall-sysv -meabi -mcpu=603e -msdata=sysv -g -O2 -fno-common -fno-keep-inline-functions -ffunction-sections -fdata-sections
   | wkspaceisunifieddefault.c         : -mcall-sysv -meabi -mcpu=603e -msdata=sysv -g -O2 -fno-common -fno-keep-inline-functions -ffunction-sections -fdata-sections
   | write.c                           : -mcall-sysv -meabi -mcpu=603e -msdata=sysv -g -O2 -fno-common -fno-keep-inline-functions -ffunction-sections -fdata-sections
   | write_r.c                         : -mcall-sysv -meabi -mcpu=603e -msdata=sysv -g -O2 -fno-common -fno-keep-inline-functions -ffunction-sections -fdata-sections
   | wsetup.c                          : -mcpu=603e -mcpu=603e -g -O2 -fno-builtin -ffunction-sections -fdata-sections

And there is the pc686 BSP with LibBSD showing the i386 issue:

   | tzset.c                               : -mtune=pentiumpro -march=i386 -g -O2 -fno-builtin -ffunction-sections -fdata-sections
   | tzset_r.c                             : -mtune=pentiumpro -march=i386 -g -O2 -fno-builtin -ffunction-sections -fdata-sections
   | tzvars.c                              : -mtune=pentiumpro -march=i386 -g -O2 -fno-builtin -ffunction-sections -fdata-sections
   | u_strerr.c                            : -mtune=pentiumpro -march=i386 -g -O2 -fno-builtin -ffunction-sections -fdata-sections
   | uart_bus_pci.c                        : -mtune=pentiumpro -march=pentium -g -O2 -ffunction-sections -fdata-sections
   | udp6_usrreq.c                         : -mtune=pentiumpro -march=pentium -g -O2 -ffunction-sections -fdata-sections -fno-strict-aliasing -ffreestanding -fno-common
   | udp_usrreq.c                          : -mtune=pentiumpro -march=pentium -g -O2 -ffunction-sections -fdata-sections -fno-strict-aliasing -ffreestanding -fno-common
   | uenvgetgroups.c                       : -mtune=pentiumpro -march=pentium -g -O2 -ffunction-sections -fdata-sections
   | uipc_accf.c                           : -mtune=pentiumpro -march=pentium -g -O2 -ffunction-sections -fdata-sections -fno-strict-aliasing -ffreestanding -fno-common
   | uipc_domain.c                         : -mtune=pentiumpro -march=pentium -g -O2 -ffunction-sections -fdata-sections -fno-strict-aliasing -ffreestanding -fno-common

[Sebastian Huber]

Fixed in GCC 10, 11, 12, and 13.