From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 49996 invoked by alias); 7 Oct 2015 15:32:19 -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 49984 invoked by uid 89); 7 Oct 2015 15:32:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: e06smtp07.uk.ibm.com Received: from e06smtp07.uk.ibm.com (HELO e06smtp07.uk.ibm.com) (195.75.94.103) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Wed, 07 Oct 2015 15:32:17 +0000 Received: from /spool/local by e06smtp07.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 7 Oct 2015 16:32:14 +0100 Received: from d06dlp01.portsmouth.uk.ibm.com (9.149.20.13) by e06smtp07.uk.ibm.com (192.168.101.137) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 7 Oct 2015 16:32:14 +0100 X-MailFrom: uweigand@de.ibm.com X-RcptTo: gcc-patches@gcc.gnu.org Received: from b06cxnps3075.portsmouth.uk.ibm.com (d06relay10.portsmouth.uk.ibm.com [9.149.109.195]) by d06dlp01.portsmouth.uk.ibm.com (Postfix) with ESMTP id 9541A17D805D for ; Wed, 7 Oct 2015 16:32:15 +0100 (BST) Received: from d06av10.portsmouth.uk.ibm.com (d06av10.portsmouth.uk.ibm.com [9.149.37.251]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t97FWDao36503744 for ; Wed, 7 Oct 2015 15:32:13 GMT Received: from d06av10.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av10.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t97EWDxe025405 for ; Wed, 7 Oct 2015 08:32:13 -0600 Received: from oc7340732750.ibm.com (dyn-9-152-213-225.boeblingen.de.ibm.com [9.152.213.225]) by d06av10.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id t97EWDhf025397; Wed, 7 Oct 2015 08:32:13 -0600 Received: by oc7340732750.ibm.com (Postfix, from userid 500) id D248CB05; Wed, 7 Oct 2015 17:32:12 +0200 (CEST) Subject: Re: [RFA 1/2]: Don't ignore target_header_dir when deciding inhibit_libc To: hans-peter.nilsson@axis.com (Hans-Peter Nilsson) Date: Wed, 07 Oct 2015 15:32:00 -0000 From: "Ulrich Weigand" Cc: law@redhat.com, gcc-patches@gcc.gnu.org In-Reply-To: <201510061728.t96HSVHq015570@ignucius.se.axis.com> from "Hans-Peter Nilsson" at Oct 06, 2015 07:28:31 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20151007153212.D248CB05@oc7340732750.ibm.com> X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15100715-0029-0000-0000-0000045CC89F X-SW-Source: 2015-10/txt/msg00721.txt.bz2 Hans-Peter Nilsson wrote: > > > From: Ulrich Weigand > > Date: Tue, 6 Oct 2015 18:55:53 +0200 > > > > 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?) So what does "works" mean, here? Do you expect that all headers are present either in include or all in sys-include? Or is there a scenario where some headers may be in either directory, and you'd have to check separately for any header you want to access? > > 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". So I wondering: what is your current setup? What headers do you have in sys-include, and how did they get there? I'm aware of the copying done when using --with-headers=, but this case should still work, since $target_header_dir is set directly to in this case anyway. Is there some *other* case, where you do not use --with-headers=, but still have a pre-existing sys-include directory in the prefix? Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com