Date: Sun, 31 May 2015 23:18:29 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: [PATCH 2/2] build: overhaul wrapper script system for multiple wrapper support 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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.