From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7840 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH 2/2] build: overhaul wrapper script system for multiple wrapper support Date: Sun, 31 May 2015 23:18:29 -0400 Message-ID: <20150601031829.GW17573@brightrain.aerifal.cx> References: <1432918126-27741-1-git-send-email-hi@shiz.me> <1432918512-27823-1-git-send-email-hi@shiz.me> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1433128726 15262 80.91.229.3 (1 Jun 2015 03:18:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 1 Jun 2015 03:18:46 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-7852-gllmg-musl=m.gmane.org@lists.openwall.com Mon Jun 01 05:18:46 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1YzGFQ-0008DU-Be for gllmg-musl@m.gmane.org; Mon, 01 Jun 2015 05:18:44 +0200 Original-Received: (qmail 13701 invoked by uid 550); 1 Jun 2015 03:18:42 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 13680 invoked from network); 1 Jun 2015 03:18:42 -0000 Content-Disposition: inline In-Reply-To: <1432918512-27823-1-git-send-email-hi@shiz.me> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:7840 Archived-At: 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