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

[Rich Felker <dalias@libc.org>]

On Fri, May 29, 2015 at 06:55:12PM +0200, Shiz wrote:
> this overhauls part of the build system in order to support multiple
> toolchain wrapper scripts, as opposed to solely the musl-gcc wrapper as
> before. it thereby replaces --enable-gcc-wrapper with --enable-wrapper=...,
> which has the options 'auto' (the default, detect whether to use wrappers),
> 'all' (build and install all wrappers), 'no' (don't build any) and finally
> the options named after the individual compiler scripts (currently 'clang'
> and 'gcc' are available) to build and install only that wrapper.
> the old --enable-gcc-wrapper is removed from --help, but still available.
> 
> it also modifies the wrappers to use the C compiler specified to the build
> system as 'inner' compiler, when applicable. as wrapper detection works by
> probing this compiler, it may not work with any other.

I believe there's still some change of behavior here that also
violates the principle of least surprise:

For the old option:

yes -- forcibly build wrapper regardless of
compiler or existing-musl-target detection

auto -- build depends on 2 conditions: $CC being gcc and not being
musl-targeted

no -- never build

For the new option:

yes or auto (same) -- build of gcc wrapper depends on 2 conditions:
$CC being gcc and not being musl-targeted. build of clang wrapper
depends only on one condition: $CC being clang.

gcc - unconditionally build gcc wrapper, never build clang wrapper

clang - unconditionally build clang wrapper, never build gcc wrapper

no -- never build

The most surprising part, which I think really should be fixed before
this is committed, is that the clang wrapper is built if you compile
musl with clang on a musl-native system. (Note that the gcc test right
now for musl-native is also wrong if the gcc toolchain omits dynamic
linking support entirely, but that's an existing bug, not a
regression.)

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

If this is acceptable, it would probably make sense to do this change
before adding the clang wrapper infrastructure so that the clang
wrapper tests can use the result of it.

Rich