musl detection by preprocessor

musl detection by preprocessor

[Jens Gustedt]

[-- Attachment #1: Type: text/plain, Size: 1054 bytes --]

Hi everybody,
I was trying to compile my P99 test cases with musl and ran into
difficulties. Not because it has bugs, but the inverse, because it is
missing bugs that glibc has :)

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

to the cpp_options section of musl-gcc.specs.sh

(I wouldn' know how to produce that version number automatically)

What do you think?

Best

Jens

-- 
:: INRIA Nancy Grand Est :: http://www.loria.fr/~gustedt/   ::
:: AlGorille ::::::::::::::: office Nancy : +33 383593090   ::
:: ICube :::::::::::::: office Strasbourg : +33 368854536   ::
:: ::::::::::::::::::::::::::: gsm France : +33 651400183   ::
:: :::::::::::::::::::: gsm international : +49 15737185122 ::



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: musl detection by preprocessor

[Szabolcs Nagy]

* Jens Gustedt <jens.gustedt@inria.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
> 

can you use #ifdef __GLIBC__ ?

Re: musl detection by preprocessor

[Jens Gustedt]

[-- Attachment #1: Type: text/plain, Size: 1275 bytes --]

Am Freitag, den 08.02.2013, 17:41 +0100 schrieb Szabolcs Nagy:
> * Jens Gustedt <jens.gustedt@inria.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
> > 
> 
> 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?

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.

Jens

-- 
:: INRIA Nancy Grand Est :: http://www.loria.fr/~gustedt/   ::
:: AlGorille ::::::::::::::: office Nancy : +33 383593090   ::
:: ICube :::::::::::::: office Strasbourg : +33 368854536   ::
:: ::::::::::::::::::::::::::: gsm France : +33 651400183   ::
:: :::::::::::::::::::: gsm international : +49 15737185122 ::



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: musl detection by preprocessor

[Szabolcs Nagy]

* Jens Gustedt <jens.gustedt@inria.fr> [2013-02-08 17:51:41 +0100]:

> Am Freitag, den 08.02.2013, 17:41 +0100 schrieb Szabolcs Nagy:
> > * Jens Gustedt <jens.gustedt@inria.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
> > > 
> > 
> > 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?
> 
> 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.
> 

ok now i understand what you want

i think you should use featuretest macros
to get a subset of the interfaces
(eg specify -D_BSD_SOURCE for all bsd things
or -D_POSIX_C_SOURCE=200809L for posix etc)

you can check the default setting in
include/features.h

strerror_r may be bad to provide under _GNU_SOURCE
but by that logic we should not provide ptrintf
under _GNU_SOURCE either as the gnu printf is
non-conformant but musl's printf is

Re: musl detection by preprocessor

[Rich Felker]

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@inria.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

Re: musl detection by preprocessor

[Jens Gustedt]

[-- Attachment #1: Type: text/plain, Size: 2335 bytes --]

Am Freitag, den 08.02.2013, 13:55 -0500 schrieb Rich Felker:
> This kind of macro intentionally isn't provided, ...
> 
> 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.)

I would completely subscribe to that logic. I see that on the compiler
side that it is much easier to work with clang's has_feature (etc)
that just with version numbers as gcc does, and where basically all
immitations of gcc get it wrong in some place.

That said, I think it would be better in turn not to rely on just that
kind of logic to provide extension features of other libraries. This
__GNUC_SOURCE thing is exactly a way how these things then go wrong.

> > 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...

Sure, usually you have to provide that information on the commandline
or through extensions (such as -std=gnu99). On POSIX systems you have
the getconf tool that provides reliable information about the
system:

getconf _POSIX_VERSION

should always work.

I probably have to review my include ordering a bit, currently I
set __GNUC_SOURCE *before* including unistd.h. I understood from their
docs that this is the way it is meant to be. Only by having it defined
before, I will in fact see the extensions they provide.

Jens

-- 
:: INRIA Nancy Grand Est :: http://www.loria.fr/~gustedt/   ::
:: AlGorille ::::::::::::::: office Nancy : +33 383593090   ::
:: ICube :::::::::::::: office Strasbourg : +33 368854536   ::
:: ::::::::::::::::::::::::::: gsm France : +33 651400183   ::
:: :::::::::::::::::::: gsm international : +49 15737185122 ::



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: musl detection by preprocessor

[Rich Felker]

On Fri, Feb 08, 2013 at 09:12:16PM +0100, Jens Gustedt wrote:
> > 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...
> 
> Sure, usually you have to provide that information on the commandline
> or through extensions (such as -std=gnu99). On POSIX systems you have
> the getconf tool that provides reliable information about the
> system:
> 
> getconf _POSIX_VERSION
> 
> should always work.

If you're on a system that has a shell, command line utilities, and
makefiles, it almost certainly has unistd.h, in which case including
unistd.h can tell you about which standards it supports.

> I probably have to review my include ordering a bit, currently I
> set __GNUC_SOURCE *before* including unistd.h. I understood from their
> docs that this is the way it is meant to be. Only by having it defined
> before, I will in fact see the extensions they provide.

Yes. The _*_SOURCE macros (called feature test macros, a rather
confusing name) are meant to be defined by the application to request
a particular featureset or conformance profile from the
implementation. Note that the standards require them to be defined
before _any_ system header is included, since it's possible (as in
glibc and its features.h) that they're processed only once, at the
time of the first inclusion of a system header. But it's also possible
that they're processed at the time of each header's inclusion. The
only portable way to use them is to define them before including any
system headers.

Rich