From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7842 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: Mon, 1 Jun 2015 10:47:44 -0400 Message-ID: <20150601144744.GX17573@brightrain.aerifal.cx> References: <1432918126-27741-1-git-send-email-hi@shiz.me> <1432918512-27823-1-git-send-email-hi@shiz.me> <20150601031829.GW17573@brightrain.aerifal.cx> <0A8B4259-3D1F-42FA-BB0C-8DE6A63F89B6@shiz.me> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1433170083 29196 80.91.229.3 (1 Jun 2015 14:48:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 1 Jun 2015 14:48:03 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-7854-gllmg-musl=m.gmane.org@lists.openwall.com Mon Jun 01 16:48:01 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 1YzR0S-0008JV-L6 for gllmg-musl@m.gmane.org; Mon, 01 Jun 2015 16:48:00 +0200 Original-Received: (qmail 24358 invoked by uid 550); 1 Jun 2015 14:47:58 -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 24338 invoked from network); 1 Jun 2015 14:47:57 -0000 Content-Disposition: inline In-Reply-To: <0A8B4259-3D1F-42FA-BB0C-8DE6A63F89B6@shiz.me> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:7842 Archived-At: On Mon, Jun 01, 2015 at 04:15:36PM +0200, Shiz wrote: > > On 01 Jun 2015, at 05:18, Rich Felker 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