Re: guard bug for strerror_r

[Rob Landley <rob@landley.net>]

On 02/08/2013 11:30:00 AM, Jens Gustedt wrote:
> Am Freitag, den 08.02.2013, 17:55 +0100 schrieb Szabolcs Nagy:
> > musl provides the posix api when requested
> >
> > musl provides many gnu specific apis when _GNU_SOURCE is set
> >
> > but when posix and gnu collides it's always the posix api,
> 
> definitively a good strategy, but which reaches its limits, here.

Packages that don't know what their limits are and never say "no" turn  
into hairballs like Mozilla, or OpenOffice, or anything the GNU/Dammit  
crowd has ever done.

> > musl never provides broken gnu apis
> >
> > at least this was the policy so far
> 
> __GNU_SOURCE is defined by the gnu platform to specify the
> availability of their extensions. Unfortunately they don't have a
> finer grained tool to distinguish different types of extensions they
> provide. (BTW the same holds for gcc, that you only can tune with
> version numbers.)
> 
> If I, as a user, define __GNU_SOURCE I expect to have the gnu
> extension, if I then use strerror_r I expect to have their interface,


Sucks to be you then.

Musl is never going to provide 100% of what glibc does. The package you  
want is called "glibc".

> since this is documented like this. At least as it is now, I don't
> think I have any means to distinguish the two platforms and to know
> which version of strerror_r I would receive.

I think everybody is expected to patch their own __MUSL__ macro into  
their local builds. A bit like the way mksquashfs was out of tree  
forever, and union mounts still are, or the way I maintain perl removal  
patches...

Although why you want the libc defined as a compiler builtin when  
that's not even the way glibc does it is beyond me. (#include  
<features.h> is even there on the mac, if I recall. That's something  
musl does have, and what you'd patch a #define __MUSL__ into.)

Rob