Re: Detecting musl at compile and/or configure time

[Samuel Holland <samuel@sholland.org>]

Hi,

On 6/30/19 7:03 AM, Chris Hall wrote:
> I have a little build system which tries to detect the "usual suspects"
> automatically, even without a full configure/cmake/etc. step.  If the detection
> process fails, it generates a warning and the user must (at least) add a '-Dxxx'
> to suppress that.
> 
> I confess I have only recently stumbled across musl.  Perhaps systems which
> default to musl are so rare that I can, as a practical matter, ignore them ? 
> The question then is whether to add a '-DqLIB_MUSL' gizmo to my build stuff --
> so that "musl-gcc -DqLIB_MUSL" will do the trick.

The fundamental problem with that is that you're not really checking for musl.
You're checking for "the supported version (and options) of POSIX", "the
supported version of the Linux UAPI", and "the set of extensions currently
supported by musl", which all change over time. And some of them depend on who's
distributing musl, as they may add their own customizations.

For POSIX, you should declare which version of the standard you follow with
_POSIX_C_SOURCE, which you can verify is supported with _POSIX_VERSION, or for
optional parts, the other macros in unistd.h[1].

The Linux UAPI is stable, so you can use whatever features you want as long as
you gracefully handle ENOSYS/EINVAL (or document a minimum supported version).

Extensions (anything not specified by POSIX or in the UAPI) must be detected
individually, because they may appear (or disappear! like sys/sysmacros.h) at
any time. If you know which extensions you rely on, and have fallbacks as
possible/needed, then it doesn't matter what the libc is named, or what it's
version number is. And it will be much easier to port your application to a new
environment.

[1]: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/unistd.h.html

> Thanks,
> 
> Chris
> 

Cheers,
Samuel