From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 66236 invoked by alias); 6 Oct 2015 17:28:37 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 66227 invoked by uid 89); 6 Oct 2015 17:28:36 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: bastet.se.axis.com Received: from bastet.se.axis.com (HELO bastet.se.axis.com) (195.60.68.11) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 06 Oct 2015 17:28:36 +0000 Received: from localhost (localhost [127.0.0.1]) by bastet.se.axis.com (Postfix) with ESMTP id B5C231811E; Tue, 6 Oct 2015 19:28:33 +0200 (CEST) Received: from bastet.se.axis.com ([IPv6:::ffff:127.0.0.1]) by localhost (bastet.se.axis.com [::ffff:127.0.0.1]) (amavisd-new, port 10024) with LMTP id JRXcrZNqhkTk; Tue, 6 Oct 2015 19:28:32 +0200 (CEST) Received: from boulder.se.axis.com (boulder.se.axis.com [10.0.2.104]) by bastet.se.axis.com (Postfix) with ESMTP id B47FC180B3; Tue, 6 Oct 2015 19:28:32 +0200 (CEST) Received: from boulder.se.axis.com (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id 9CD92132A; Tue, 6 Oct 2015 19:28:32 +0200 (CEST) Received: from thoth.se.axis.com (thoth.se.axis.com [10.0.2.173]) by boulder.se.axis.com (Postfix) with ESMTP id 9015D115A; Tue, 6 Oct 2015 19:28:32 +0200 (CEST) Received: from ignucius.se.axis.com (ignucius.se.axis.com [10.88.21.50]) by thoth.se.axis.com (Postfix) with ESMTP id 8CE9234009; Tue, 6 Oct 2015 19:28:32 +0200 (CEST) Received: from ignucius.se.axis.com (localhost [127.0.0.1]) by ignucius.se.axis.com (8.12.8p1/8.12.8/Debian-2woody1) with ESMTP id t96HSWDi015574; Tue, 6 Oct 2015 19:28:32 +0200 Received: (from hp@localhost) by ignucius.se.axis.com (8.12.8p1/8.12.8/Debian-2woody1) id t96HSVHq015570; Tue, 6 Oct 2015 19:28:31 +0200 Date: Tue, 06 Oct 2015 17:28:00 -0000 Message-Id: <201510061728.t96HSVHq015570@ignucius.se.axis.com> From: Hans-Peter Nilsson To: uweigand@de.ibm.com CC: law@redhat.com, gcc-patches@gcc.gnu.org In-reply-to: <20151006165553.7E5D9DAD@oc7340732750.ibm.com> (message from Ulrich Weigand on Tue, 6 Oct 2015 18:55:53 +0200) Subject: Re: [RFA 1/2]: Don't ignore target_header_dir when deciding inhibit_libc MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT X-SW-Source: 2015-10/txt/msg00610.txt.bz2 > From: Ulrich Weigand > Date: Tue, 6 Oct 2015 18:55:53 +0200 > Hans-Peter Nilsson wrote: > > > Sanity-check: you do have a $target_header_dir/stdio.h right? > > Well, no. That was the point of my original mail :-) But you apparently have something that *would* fit. > > Maybe make with_headers=yes (i.e. not a path) have the effect of > > setting target_header_dir to include instead of sys-include? (...and inspect both, use the first one that works?) > That would solve my problem. However, if with_headers is not set at all, > shouldn't we then *also* set it to include? Definitely not, only one reason of several being as that'd break current use. > I don't really particularly want to use --with-headers, it's just that > this is what worked in the past. Ideally, it would be best if everything > just worked as expected without any option if there are indeed already > headers installed in the prefix. --enable-dwim? :] > > Anyway, with_headers=yes/no should simply short-circuit an > > inspection of $target_header_dir regarding setting inhibit_libc. > > I guess. But then again, target_header_dir really needs to be > > set usefully for inspection, or else every use of it needs to be > > dominated by a with_headers=yes test or something. > > Well, every other use of $target_header_dir does not in fact matter > on the SPU (because they check for features that aren't present in > newlib and/or on the SPU anyway). That's why the weird behaviour > did not really matter in the past ... > > So short-circuting just for inhibit_libc would get everything back > to where we were before your patch. But I agree this is not really > the right solution. > > My preferred solution would be to set $target_header_dir to include > instead of sys-include, always. I'm just a bit worried if this may > break other users that have a workflow that somehow works with the > current setup using sys-include. (T would: proof of existence here.) I'm more than worried! Please don't suggest to change a toolchain configuration item only because you used something that half-way worked, then broke, like this. Not the least when also saying the below: > I guess my underlying problem is > that I don't quite understand how the whole sys-include thing was > intended to work in the first place ... I don't know when "include" will work and not, in particular compared to "sys-include". > [ Note there's also CROSS_SYSTEM_HEADER_DIR, which is also sometimes > set to sys-include ... ] Always, in the absence of sysroot. brgds, H-P