[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9defa08c-cd41-904c-bff7-eb6c503bba2f@gmch.uk>
Date: Sun, 30 Jun 2019 15:30:32 +0100
From: Chris Hall <musl@...h.uk>
To: musl@...ts.openwall.com
Subject: Re: Detecting musl at compile and/or configure time
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
