Date: Fri, 8 Feb 2013 13:55:17 -0500 From: Rich Felker <dalias@...ifal.cx> To: musl@...ts.openwall.com Subject: Re: musl detection by preprocessor 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 <jens.gustedt@...ia.fr> [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 <sys/cdefs.h> and <features.h>. Including these yourself is not portable, but if you just include <stddef.h> 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 <unistd.h>, 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
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.