| Subject: | Define _GNU_SOURCE as part of build |
glibc's position on namespaces, at least under Ulrich Drepper's
leadership, was that everything not in POSIX should be off by default
unless it was present in ancient BSD and System V. Programs are
encouraged to define _GNU_SOURCE to enable extensions. See, for
example:
https://sourceware.org/bugzilla/show_bug.cgi?id=6775
This position has created at least three problems for us:
* asprintf is not declared in stdio.h by default (r19735; I suspect this
is only needed for Linux, but can't be certain).
* EAI_NODATA is not declared in netdb.h by default but can be returned
by getaddrinfo (#7526).
* ip6_pktinfo is not declared in netinet/in.h by default even though it
is on basically all other modern platforms (#7960).
Declaring _GNU_SOURCE has at least one negative consequence we must be
aware of: it causes a non-POSIX version of strerror_r to be declared.
There may be other consequences I'm not yet aware of. But it seems
plausible that in the long run, defining _GNU_SOURCE would solve more
problems than it creates. I am confident that _GNU_SOURCE creates no
ABI compatibility issues between libraries which use it and applications
which don't, so the issues would be limited to our own correctness.
We would need to define _GNU_SOURCE early in configure.in so that it is
available for configure tests. We can define it explicitly with
AC_DEFINE, we can use the deprecated AC_GNU_SOURCE, or we can use
AC_USE_SYSTEM_EXTENSIONS which would also define certain symbols on
other platforms as well. If we use the latter, we would need to test
the build on Solaris/FreeBSD/OS X. AC_USE_SYSTEM_EXTENSIONS is new in
autoconf 2.59c (we currently require 2.52).
A brief survey of other open-source software finds:
* Heimdal defines _GNU_SOURCE explicitly.
* cpython uses AC_USE_SYSTEM_EXTENSIONS and also defines _GNU_SOURCE
explicitly. (I think the cpython configure script took a wrong turn at
some point because it's mucking around with _POSIX_C_SOURCE and
_XOPEN_SOURCE.)
* remctl and krb5-strength use AC_USE_SYSTEM_EXTENSIONS. Probably other
rra software does as well.
* Samba uses _GNU_SOURCE at least in some builds (it shows up in some
packaging files).
* sssd uses AC_USE_SYSTEM_EXTENSIONS or AC_GNU_SOURCE depending on the
autoconf version.
* OpenLDAP defines _GNU_SOURCE in a couple of specific source files.
* OpenSSL defines _GNU_SOURCE in one specific file (to get dladdr).
* FreeIPA defines _GNU_SOURCE in several source files.
leadership, was that everything not in POSIX should be off by default
unless it was present in ancient BSD and System V. Programs are
encouraged to define _GNU_SOURCE to enable extensions. See, for
example:
https://sourceware.org/bugzilla/show_bug.cgi?id=6775
This position has created at least three problems for us:
* asprintf is not declared in stdio.h by default (r19735; I suspect this
is only needed for Linux, but can't be certain).
* EAI_NODATA is not declared in netdb.h by default but can be returned
by getaddrinfo (#7526).
* ip6_pktinfo is not declared in netinet/in.h by default even though it
is on basically all other modern platforms (#7960).
Declaring _GNU_SOURCE has at least one negative consequence we must be
aware of: it causes a non-POSIX version of strerror_r to be declared.
There may be other consequences I'm not yet aware of. But it seems
plausible that in the long run, defining _GNU_SOURCE would solve more
problems than it creates. I am confident that _GNU_SOURCE creates no
ABI compatibility issues between libraries which use it and applications
which don't, so the issues would be limited to our own correctness.
We would need to define _GNU_SOURCE early in configure.in so that it is
available for configure tests. We can define it explicitly with
AC_DEFINE, we can use the deprecated AC_GNU_SOURCE, or we can use
AC_USE_SYSTEM_EXTENSIONS which would also define certain symbols on
other platforms as well. If we use the latter, we would need to test
the build on Solaris/FreeBSD/OS X. AC_USE_SYSTEM_EXTENSIONS is new in
autoconf 2.59c (we currently require 2.52).
A brief survey of other open-source software finds:
* Heimdal defines _GNU_SOURCE explicitly.
* cpython uses AC_USE_SYSTEM_EXTENSIONS and also defines _GNU_SOURCE
explicitly. (I think the cpython configure script took a wrong turn at
some point because it's mucking around with _POSIX_C_SOURCE and
_XOPEN_SOURCE.)
* remctl and krb5-strength use AC_USE_SYSTEM_EXTENSIONS. Probably other
rra software does as well.
* Samba uses _GNU_SOURCE at least in some builds (it shows up in some
packaging files).
* sssd uses AC_USE_SYSTEM_EXTENSIONS or AC_GNU_SOURCE depending on the
autoconf version.
* OpenLDAP defines _GNU_SOURCE in a couple of specific source files.
* OpenSSL defines _GNU_SOURCE in one specific file (to get dladdr).
* FreeIPA defines _GNU_SOURCE in several source files.