Re: [PATCH 2/2] build: overhaul wrapper script system for multiple wrapper support

[Rich Felker <dalias@libc.org>]

On Mon, Jun 01, 2015 at 04:15:36PM +0200, Shiz wrote:
> > On 01 Jun 2015, at 05:18, Rich Felker <dalias@libc.org> wrote:
> > 
> > Even if that's fixed, it's also a problem, I think, that yes/auto are
> > equated. Presumably someone using --enable-wrapper with an existing
> > musl-targeted toolchain would want to bypass the musl-native detection
> > and force the wrapper (whichever one is appropriate for their
> > compiler) to be built.
> 
> You’re right, this is something that should be addressed. I’ll fix that.
> 
> > This is especially important to have if the
> > musl-native test has false positives, which I think it will if we take
> > the following approach I'd like to take:
> > 
> > Instead of testing for musl-native, test whether the toolchain is
> > targetting another known non-musl target, which is basically a matter
> > of #ifdef __GLIBC__. This ensures that the wrapper is never auto-built
> > for a musl-native system (which could happen before if the musl-native
> > test failed) and avoids compiler-specific hacks; we can simply have a
> > general test for known-non-native-toolchain.
> 
> I’m not sure I’m a big fan of this approach. It’s perfectly reasonable for
> targets to exist which are both not musl and don’t define __GLIBC__.
> I think a much more reasonable approach would be to check the target triple
> ($CC -dumpmachine) for *musl* - I believe any compiler which would target
> musl systems would have this in its triple right now. The reason why I
> omitted the detection in the initial patch was because I wanted some more
> time to think the approach over, I should’ve mentioned that in the message.
> clang, gcc and cparser all support -dumpmachine, and we already presume a
> gcc-ish command line interface for a lot of things, so I wouldn’t see any
> harm in taking this approach. pcc doesn’t support this sadly, however.
> 
> Any thoughts?

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

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.
This isn't terribly difficult, since the main essential thing that
needs to be patched is the libstdc++ glibcism. Most of the rest of
musl-cross is "re-teaching" gcc that some important features it
enables only for glibc are not glibc-only (but this may not be needed
if gcc already thinks musl is a *-gnu target). In any case I'm pretty
sure there are users of musl using it with toolchains that output
???-linux-gnu as their -dumpmachine, and I don't expect to see this
phased out quickly.

Rich