From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14311 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Chris Hall Newsgroups: gmane.linux.lib.musl.general Subject: Re: Detecting musl at compile and/or configure time Date: Sun, 30 Jun 2019 15:30:32 +0100 Message-ID: <9defa08c-cd41-904c-bff7-eb6c503bba2f@gmch.uk> References: <26f5537f-a876-209c-a27c-cd2619f5c834@gmch.uk> <3767f116-4a52-e9ef-a2ee-df1c23719e34@gmch.uk> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="244540"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 To: musl@lists.openwall.com Original-X-From: musl-return-14327-gllmg-musl=m.gmane.org@lists.openwall.com Sun Jun 30 16:30:47 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1hhaqt-0011X8-O9 for gllmg-musl@m.gmane.org; Sun, 30 Jun 2019 16:30:47 +0200 Original-Received: (qmail 17860 invoked by uid 550); 30 Jun 2019 14:30:45 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 17842 invoked from network); 30 Jun 2019 14:30:44 -0000 In-Reply-To: Content-Language: en-GB Xref: news.gmane.org gmane.linux.lib.musl.general:14311 Archived-At: 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