%m, #614

[Achim Gratz]

Richard Laager via devel writes:
> I haven't fact checked you, but what you're saying about the APIs sounds
> reasonable. Is there any chance you could propose a patch to fix this?
> (Or have you already and I missed it?)

There is no single right solution to this, but there are  several completely
wrong ones.

Let's go back from where ntpsec is right now:

--8<---------------cut here---------------start------------->8---
    # FIXME: We'd like this to be -D_POSIX_C_SOURCE=200809L -D_XOPEN_SOURCE=600
    # rather than -D_GNU_SOURCE, but that runs into problems in two places:
    # (1) The ISC net handling stuff, where struct in6_addr’ loses a member
    # named s6_addr32 that the macros need, and (2) three BSD functions
    # related to chroot jailing in the sandbox code.
    #
    # Note that _POSIX_C_SOURCE >= 199506L and _GNU_SOURCE both turn on
    # _POSIX_PTHREAD_SEMANTICS and _REENTRANT
    #
    ctx.env.CFLAGS = ["-std=c99", "-D_GNU_SOURCE"] + ctx.env.CFLAGS
--8<---------------cut here---------------end--------------->8---

This is plain wrong, since _GNU_SOURCE doesn't give you POSIX semantics
when there is a GNU API for the same function (plus it's generally hit
and miss when you confront a non-glibc system with that definition).
You also can't usefully combine _GNU_SOURCE with most feature test
macros because it is designed to override all those it thinks it needs,
rather than cooperate.  It also introduces further precedence rules:
POSIX will override BSD and SVID and GNU specific interfaces will be
preferred over POSIX (the case with strerror_r).  What exactly
_GNU_SOURCE does has evolved a bit over time, too (e.g. whether
_BSD_SOURCE is included in the effect and whether it does take
precedence over POSIX).

The alluded to "-D_POSIX_C_SOURCE=200809L -D_XOPEN_SOURCE=600" does work
for the most part, but misses some API that ntpsec happens to use,
albeit undeclared (the s6_addr32 falls into that category).  Again it's
more of a happy side-effect that _GNU_SOURCE happens to make those
visible, so you're better off figuring out what exactly would enable
them in the absence of _GNU_SOURCE.  In current Linux/glibc these are
controlled by the internal __USE_MISC, which in turn gets set when
_DEFAULT_SOURCE is in effect (it also deactivates __STRICT_ANSI__).  It
is a combination of the effects of _SVID_SOURCE and _BSD_SOURCE, which
are both deprecated, but not yet warned about when used in conjunction
with _DEFAULT_SOURCE.

So we're here now: short version "-D_DEFAULT_SOURCE
-D_POSIX_C_SOURCE=200809L -D_XOPEN_SOURCE=600" for newish systems and
long version " -D_DEFAULT_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE
-D_POSIX_C_SOURCE=200809L -D_XOPEN_SOURCE=600" for older ones we may not
care about anymore.

Why not use that unconditionally?  Well, it doesn't work with glibc
before 2.10 and still buggy in many places until about version 2.14 (or
2.13, I forget).  Prominent holdouts for older glibc versions are
RHEL5/CentOS5 (already two years EOL, but still used).  RHEL6/CentOS6
has a nominally working glibc-2.12, but e.g. strerror_r is not POSIX
compatible yet (EOL in 2020/11).  According to Distrowatch, Debian is
clear since Wheezy, openSuSE since 12.1, Gentoo since 11.2.  But there
are distributions that use a different libc: Alpine is using musl, which
however should work with the longer version of the defines above, based
on the documentation (I have no personal experience with it).

That leaves all the BSD plus OSX (which again differs depending on which
toolchain you employ, IUC).  OSX should fall closer to the BSD side than
glibc in any case.  I don't know much about these, but on OpenBSD at
least the POSIX and XOPEN macros actively switch off the BSD API, which
you can apparently get back by additionally defining __BSD_VISIBLE to 1
again (again, I have no personal experience).  The advice for porting to
the BSD family commonly is to not define either POSIX and XOPEN macros
since the standard compilation environment is "everything plus the
kitchen sink" and any feature test macro gets you a restricted API you
may not be prepared to deal with.  You have to be careful to not specify
an implicit feature test definition via the language specification of
the compiler driver (i.e. don't turn on strict ANSI compliance, so
-std=gnu99 instead of -std=c99).

So the configury in wscript should at least distinguish new enough
glibc, too old glibc and anything else, each with their own set of
defines.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs