Bug 15124

Most of the Linux-specific features exposed by glibc that aren't covered by another legacy profile (svr4, bsd, etc.) are only available if _GNU_SOURCE is defined by the application. This includes mmap flags, clone and clone flags, cpuset and affinity settings, fcntl flags/commands, etc.

The problem with this arrangement is that _GNU_SOURCE also breaks certain standard interfaces (at least strerror_r, but there may be others). Thus, a program that needs both the Linux-specific features and non-broken, conforming strerror_r, has no recourse but to split up translation units such that all of the extensions are accessed only from small translation units that don't need interfaces that might be broken by defining _GNU_SOURCE. This is a really ugly mess.

To resolve the issue, some method for indicating "want GNU extensions, but prefer standards whenever there's a conflict" should be available. Ideally this would be the behavior of defining both _GNU_SOURCE and _POSIX_C_SOURCE or _XOPEN_SOURCE, but if the risk of breaking existing applications is too great, another approach would be acceptable. What's not acceptable is the current situation where there's no way to say "I want to add extensions" without also saying "I want to break standard functions".