[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
