We test once whether __GLIBC__ is not defined, so we do not need to test
whether it is on the OR branch afterwards. We decouple the glibc version
restriction check from the _*_SOURCE variable, as that contains an
implicit opposite version check.
On non-glibc based systems we cannot unconditionally use the
__GLIBC_PREREQ macro as it gets expanded before evaluation. Instead,
if it is undefined, define it to 0.
We should also always declare these functions on non-glibc based
systems. And on systems with a new enough glibc, which provides these
functions, we should still provide the declarations if _GNU_SOURCE
is *not* defined.
Reported-by: Jörg Krause <joerg.krause@embedded.rocks>
This is a non-portable header, and we cannot expect it to be provided by
the system libc (e.g. musl). We just need and rely on declaration that
we have defined ourselves in our own <bsd/sys/cdefs.h>. So we switch to
only ever assume that.
Fixes: https://bugs.freedesktop.org/105281
We mention that these are now superseded by the glibc implementations,
make the headers cope with already declared functions on glibc-based
systems, and document this in the man pages.
Glibc tends to include standard headers with special definitions
that make few declarations or macros visible, this stomps over the
overlay #include_next <> logic.
Based-on-patch-by: Robert Millan <rmh@debian.org>
These inclusions were in place for backward compatibility purposes,
when the headers were split so that code using them would not break.
Make it possible for applications to disable them by defining
LIBBSD_CLEAN_INCLUDES so that buildability can be tested and fixed
before they get removed in a subsequent release.
This means that software being ported should not need to be modified in
the usual case, as the libbsd headers will take over the standard
namespace and fill the missing gaps, and include the system headers.
To use this the new libbsd-transparent.pc file can be used through
pkg-config, which should end up doing the right thing.
