[build] possible misuse of -D_GNU_SOURCE (also causing warning: "_GNU_SOURCE" redefined)

[sleeptightAnsiC]

Originated and partially discussed in #4720

When compiling rglfw.c from Makefile with recent versions of GCC or Clang, following warning appears:

external/glfw/src/posix_poll.c:27:9: warning: "_GNU_SOURCE" redefined
   27 | #define _GNU_SOURCE
      |         ^~~~~~~~~~~
<command-line>: note: this is the location of the previous definition

which is happening because Makefile uses -D_GNU_SOURCE when compiling said source.

It has been noticed that some build systems (sec/Makefile, build.zig) define _GNU_SOURCE at command line while others do not (Cmake) and also define different -std=c99/-std=gnu99 which may potentially lead to inconsistencies in glibc behavior depending on build system (see comments under linked PR).

Environment

$ uname -a
Linux MAL200424 6.12.10-arch1-1 #1 SMP PREEMPT_DYNAMIC Sat, 18 Jan 2025 02:26:57 +0000 x86_64 GNU/Linux

Code Example

$ git clone https://github.com/raysan5/raylib.git
$ cd raylib/src
$ make rglfw.o CC=gcc
gcc  -c rglfw.c -Wall -D_GNU_SOURCE -DPLATFORM_DESKTOP_GLFW -DGRAPHICS_API_OPENGL_33 -Wno-missing-braces -Werror=pointer-arith -fno-strict-aliasing -std=c99 -fPIC -O1 -Werror=implicit-function-declaration -D_GLFW_X11  -I.  -Iexternal/glfw/include
In file included from rglfw.c:99:
external/glfw/src/posix_poll.c:27:9: warning: "_GNU_SOURCE" redefined
   27 | #define _GNU_SOURCE
      |         ^~~~~~~~~~~
<command-line>: note: this is the location of the previous definition

cc @Peter0x44 as discussed

[sleeptightAnsiC]

Unless I'm mistaken, -std=* and __SOURCE define different things. -std= define language features and __SOURCE define library features. So, for example, -D_GNU_SOURCE -std=c99 or -D_DEFAULT_SOURCE -std=gnu99 should be both valid, just being a matter of defining what's required and where.

It's not exactly true. -std can also affect the behavior of libc a bit:

$ echo | gcc -std=gnu99 -dM -E -o gnu99.txt -
$ echo | gcc -std=c99 -dM -E -o c99.txt -
$ diff c99.txt gnu99.txt | grep '<'
< #define __STRICT_ANSI__ 1
< #define __FLT32_HAS_INFINITY__ 1
$ diff c99.txt gnu99.txt | grep '>'
> #define __STDC_UTF_16__ 1
> #define unix 1
> #define __FLT32_HAS_INFINITY__ 1
> #define linux 1
> #define __STDC_UTF_32__ 1

in this case it defines __STRICT_ANSI__ which then defines _DEFAULT_SOURCE inside of glibc (ref) which then changes some stuff internally in how libc works, but yes, it does not predefine _GNU_SOURCE, that was our main concern (mentioned here).

Tested removing -D_GNU_SOURCE here and everything appears to compile as expected on Linux Mint 22.0

But does it change any runtime behavior though? We wanna remove -D_GNU_SOURCE from those build systems, but we are afraid that it may change behavior of some libc call and introduce hard to catch bug.

[sleeptightAnsiC]

^ edited @asdqwe

[Peter0x44]

 # Compile rglfw module
 rglfw.o : rglfw.c
-       $(CC) $(GLFW_OSX) -c $< $(CFLAGS) $(INCLUDE_PATHS)
+       $(CC) $(GLFW_OSX) -c $< $(CFLAGS) $(INCLUDE_PATHS) -U_GNU_SOURCE

I suspect this might be the best fix we can come up with for now

[Peter0x44]

Unfortunately there is no easy way to apply a flag to just a single file in a target in cmake as far as I can tell.

Considering the warning is harmless and in a rarely edited file, it is probably not worth the effort to make it work everywhere.

[Peter0x44]

Also relevant reading for this issue:
man feature_test_macros
https://man.archlinux.org/man/core/man-pages/feature_test_macros.7.en
https://ariadne.space/2021/12/21/stop-defining-feature-test-macros-in-your-code/

Of course, we don't control glfw so can't dictate what it does.

[Peter0x44]

Actually, CMake does not use rglfw.c so it isn't a problem there.
I will submit this change, if zig and premake users want a fix they can figure it themselves.

[sleeptightAnsiC]

Thanks @Peter0x44

This is so funny that GLFW defines said macro and then goes with 3 different build paths anyway, just to get correct poll(3p)