Should we define _GNU_SOURCE in SwiftGlibc?

[Karl]

This topic has come up a couple of times in the past:

• Defining _GNU_SOURCE for module-map-included headers (2015)
• Libc portability, _GNU_SOURCE, platform checks... oh my (2017)

The latter post has some especially interesting details. Apparently they investigated this and found the source breakage to be minimal:

@Zac_Bowling

After investigating, the only source breaking change this causes is
specifically with the strerror_r() function which changes it's signature
when _GNU_SOURCE is defined (it returns a char* instead of an int). I'm not
sure how wide spread this function is used in Swift code directly today (I
know that swiftpm uses it which is what broke when we tried this change on
Linux).

These days, we generate SwiftGlibC by pre-compiling a header file (well, a gybed header file), so it's a lot easier to add these sorts of feature macros without touching the compiler/clang importer.

Adding this would expose a lot of really useful platform functionality. If we can figure out the source breakage (if it even still applies), I think this would be a worthwhile change. Thoughts?

[H-G-Hristov (Hristo Hristov)]

Well, I'd like to be able to use some extended features which are available on macOS but I was surprised that they aren't on Linux:

posix_spawn

[mickeyl (Dr. Mickey Lauer)]

Yes, please!

[3405691582]

I don't know if it makes sense to do this and I'd be concerned that it'd affect portability of the base Swift compiler. For end users I believe there should be workarounds (just create a bridging header, define it there, and reinclude headers?)

[H-G-Hristov (Hristo Hristov)]

Do you mean to create the modules (Glibc) from scratch or something could be reused?