> On 01 Jun 2015, at 16:47, Rich Felker <dalias@libc.org> wrote:
> 
> There are two reasons I prefer the approach I described:
> 
> 1. It's better not to auto-enable wrappers unless we're pretty
> confident they work. The wrappers are not magically universal; they're
> a way to use musl with a preexisting non-musl-targeted toolchain that
> meets a fairly large set of internal assumptions, and they won't
> necessarily work with arbitrary toolchains. In particular I'm pretty
> sure musl-gcc does not work with Rob's toolchains from Aboriginal
> Linux that are using their own wrapper (named gcc) around an internal
> gcc elsewhere, and presumably (being uclibc based) these would even be
> detected as "ok for wrapper”.

I’d like to note that a __GLIBC__ check would not help here either
presumably, as uclibc defines __GLIBC__ as well. :)

> 2, A false positive for enabling the wrapper (installing it on a
> musl-native system) is worse than a false-negative (omitting it) since
> native systems/cross-compilers are intended as the first-class usage
> case and wrappers are more of a demo/minor usage case. I can't safe
> for sure, but I suspect there might be minor breakage (versus a
> full-featured native toolchain) in using the wrappers on top of an
> already-native toolchain, and I don't want to ྀmislead users to do this
> by installing a script that looks like it's meant to be used.
> 
> I don't believe the dumpmachine approach is at all robust for gcc
> versions less than gcc 6 where musl support is upstream, and it's
> worse than the current dynamic linker check. There are no musl-cross
> patches at all for gcc versions prior to 4.0.3, whereas gcc3 works
> well and some dists (e.g. Sabotage) are even using it to bootstrap.

Understood, I wasn’t aware of this. On Gentoo’s musl profile, the gcc
CHOST is reconfigured to $arch-gentoo-linux-musl, so -dumpmachine works
as expected on every gcc it builds:

# gcc -dumpmachine
x86_64-gentoo-linux-musl

I assumed other musl distros would do something similar.

So I see your use case for testing in C code itself as opposed to testing
compiler features. That being said, I’m still not at all a fan of __GLIBC__,
for reasons mentioned in the previous post. While a false-positive is worse
than a false-negative, I feel just solely testing for this provides a large
opportunity for false-negatives, and even some false positives as you yourself
mentioned in point one.

It’s a tough thing to check thoroughly and accurately, but I do not think
checking __GLIBC__ is at all the solution either.

-S