Re: Detecting musl at compile and/or configure time

[Chris Hall <musl@gmch.uk>]

On 30/06/2019 13:28, Samuel Holland wrote:
> 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.
...
> 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).

My experience with Linux and BSD is that setting _POSIX_C_SOURCE and/or 
_XOPEN_SOURCE does not work very well.  For BSD it tends to rule out 
stuff I need -- notably in the area of sockets.  So, I have found it is 
more practical to declare _GNU_SOURCE for Linux and nothing at all for 
the BSDs and try to stick to the common areas.  The big differences 
between Linux and the BSDs you just have to deal with, in any case.

> 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.

I accept that the only way to be absolutely sure of any given extension 
(or local interpretation of some Standard) is to do the required tests 
at configure/cmake/etc time.

Nevertheless, I think it is possible to get a long way without a 
configure/cmake/etc step... much/most of the time.  And where something 
very specific needs to be configured, the more common stuff still does 
not (simplifying the configure step).

I agree that, in this context, the libc is of less interest than the 
underlying OS.

Nevertheless, I see no reason not to detect the libc, where I can.

Clearly musl falls into the (small) category of libc where I cannot.

Thanks,

Chris