From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 42346 invoked by alias); 30 Jan 2018 18:36:57 -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 42326 invoked by uid 89); 30 Jan 2018 18:36:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.7 required=5.0 tests=AWL,BAYES_00,KAM_INFOUSMEBIZ,KAM_LAZY_DOMAIN_SECURITY,KAM_SHORT,RDNS_DYNAMIC,URIBL_SBL autolearn=no version=3.3.2 spammy=H*M:info, foreign, H*F:D*info X-Spam-User: qpsmtpd, 2 recipients X-HELO: void-ptr.info Received: from pppoe.185.44.68.223.lanport.ru (HELO void-ptr.info) (185.44.68.223) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 30 Jan 2018 18:36:55 +0000 Received: from ptr by void-ptr.info with local (Exim 4.72) (envelope-from ) id 1egam3-0004aJ-W8; Tue, 30 Jan 2018 21:36:52 +0300 Date: Tue, 30 Jan 2018 20:06:00 -0000 From: Petr Ovtchenkov To: Jonathan Wakely Cc: libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org Subject: Re: [PING^3] [PATCH] Remove CANADIAN, that break compilation for foreign target Message-ID: <20180130213651.681aa73a@void-ptr.info> In-Reply-To: <20180130125421.GR3417@redhat.com> References: <20170920134459.6f1b2bcf@void-ptr.info> <20171116205537.17680878@void-ptr.info> <20171219113743.69a153a0@void-ptr.info> <20180130101943.2c35f362@void-ptr.info> <20180130125421.GR3417@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-01/txt/msg02375.txt.bz2 On Tue, 30 Jan 2018 12:54:21 +0000 Jonathan Wakely wrote: > On 30/01/18 10:19 +0300, Petr Ovtchenkov wrote: > >On Tue, 19 Dec 2017 11:37:43 +0300 > >Petr Ovtchenkov wrote: > > > >ping^3 > > > I don't fully understand the consequences (or need) for this patch. > > I asked some other people to look at it, and didn't get confirmation > it's OK. So I'm reluctant to make the change. Especially this late in > the GCC 8 cycle. Hmm, almost two years for this words. Do you really think that -I/usr/include may be correct in build of cross of some kind (CANADIAN is just variant of cross)? Of cause, I don't consider case with rolling target headers in /usr/include. > > > >> On Thu, 16 Nov 2017 20:55:37 +0300 > >> Petr Ovtchenkov wrote: > >> > >> > On Wed, 20 Sep 2017 13:44:59 +0300 > >> > Petr Ovtchenkov wrote: > >> > > >> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71212 > >> > > > >> > > On Fri, 20 May 2016 16:10:50 +0300 > >> > > Petr Ovtchenkov wrote: > >> > > > >> > > > Some old ad-hoc (adding -I/usr/include to compiler > >> > > > flags) break compilation of libstdc++ for foreign > >> > > > target architecture (due to compiler see includes > >> > > > of native). > >> > > >> > Reference for terms: > >> > > >> > https://gcc.gnu.org/onlinedocs/gccint/Configure-Terms.html > >> > > >> > Present of "CANADIAN=yes" lead to inclusion of > >> > headers from build (-I/usr/include). "CANADIAN=yes" used _only_ > >> > to set "-I/usr/include". > >> > > >> > Inclusion of build headers in cross-compilation > >> > process is not a mistake only in case of native (i.e. it is mistake > >> > for cross, for canadian, for crossed native and for crossback), > >> > but sometimes give "success". > >> > > >> > Note, that build/host/target may be different not only due to > >> > different architectures, but due to different sysroots > >> > (libc, kernel, binutils, etc.). > >> > > >> > CANADIAN is set to "yes" by code > >> > > >> > - # If Canadian cross, then don't pick up tools from the build directory. > >> > - # Used only in GLIBCXX_EXPORT_INCLUDES. > >> > - if test -n "$with_cross_host" && > >> > - test x"$build_alias" != x"$with_cross_host" && > >> > - test x"$build" != x"$target"; > >> > - then > >> > - CANADIAN=yes > >> > - else > >> > - CANADIAN=no > >> > - fi > >> > > >> > and it add "-I/usr/include" to compiler flags for building libstdc++. > >> > This is wrong. > >> > > >> > Reference to patch: > >> > https://gcc.gnu.org/ml/gcc-patches/2017-09/msg01332.html