From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2749 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: musl detection by preprocessor Date: Fri, 8 Feb 2013 13:55:17 -0500 Message-ID: <20130208185517.GI20323@brightrain.aerifal.cx> References: <1360340887.2983.352.camel@eris.loria.fr> <20130208164134.GV6181@port70.net> <1360342301.2983.361.camel@eris.loria.fr> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1360349731 21685 80.91.229.3 (8 Feb 2013 18:55:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 8 Feb 2013 18:55:31 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2750-gllmg-musl=m.gmane.org@lists.openwall.com Fri Feb 08 19:55:52 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1U3t6z-0006BF-BO for gllmg-musl@plane.gmane.org; Fri, 08 Feb 2013 19:55:49 +0100 Original-Received: (qmail 12272 invoked by uid 550); 8 Feb 2013 18:55:30 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 12264 invoked from network); 8 Feb 2013 18:55:30 -0000 Content-Disposition: inline In-Reply-To: <1360342301.2983.361.camel@eris.loria.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:2749 Archived-At: On Fri, Feb 08, 2013 at 05:51:41PM +0100, Jens Gustedt wrote: > Am Freitag, den 08.02.2013, 17:41 +0100 schrieb Szabolcs Nagy: > > * Jens Gustedt [2013-02-08 17:28:07 +0100]: > > > In short I have some problem where they (the gnus) deviate from > > > standard interfaces, here this was triggered by their different > > > iterface for strerror_r. Now the musl compiler wrapper doesn't allow > > > to distinguish a linux system with glibc or with musl (or at least I > > > didn'find one). > > > > > > Inspecting the wrapper, it looks quite easy to add something like > > > > > > -D__MUSL__=000909UL This kind of macro intentionally isn't provided, because its presence would result in the vast majority of projects treating bug reports of the form "your program does not compile against musl" with a quick hack adding "#ifdef __MUSL__ ... [omit feature or substitute in fallback definition] ... #endif". In a best case, this would harm functionality by leaving the feature out even in later musl versions that support it; in reality, it's likely to actively break build (e.g. with conflicting declarations/macros/etc.) if the feature is added to musl. My position, and the position of most people involved with the project, is that applications should test for features (e.g. with a configure script or standardized per-feature macros defined in headers) rather than hard-coding assumptions about which version of an OS/library has which features. (Note that, in the OS case, screwing this up has broken packages that assumed Linux version X lacks behavior Y, when a particular distribution backported behavior Y to version X.) > > > > > > > can you use #ifdef __GLIBC__ ? > > Hm, I don't think that this comes timely enough. Where would this be > defined, probably in some header file that I'd include, no? Any of the standard headers in glibc include and . Including these yourself is not portable, but if you just include or something else ultra-light, you should be able to get glibc-identifying macros (__GLIBC__). As soon as you determine it's safe to include , I think it would be a good idea to include that too. That's where you get _POSIX_VERSION and similar standards-defined macros, which can tell you a lot about what features the system promises to provide. > I'd like to distinguish the platform as early as possible, ideally > *before* I include any files, such that I can base decisions on which > files to include only on #defines that the pure compiler provides. I'm not sure how you can determine with just the standard macros that you're on a POSIX or POSIX-like system where you have unistd.h... Rich