From owner-freebsd-toolchain@freebsd.org Sat May 28 00:15:38 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 365C6B4A87E for ; Sat, 28 May 2016 00:15:38 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-179.reflexion.net [208.70.211.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DB8BA1799 for ; Sat, 28 May 2016 00:15:37 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 15698 invoked from network); 28 May 2016 00:16:03 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 28 May 2016 00:16:03 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Fri, 27 May 2016 20:16:08 -0400 (EDT) Received: (qmail 31042 invoked from network); 28 May 2016 00:16:08 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 28 May 2016 00:16:08 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id D686B1C43D6; Fri, 27 May 2016 17:15:18 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build) From: Mark Millard In-Reply-To: Date: Fri, 27 May 2016 17:15:30 -0700 Cc: FreeBSD Current , FreeBSD Toolchain , FreeBSD PowerPC ML , Gerald Pfeifer , Warner Losh Content-Transfer-Encoding: quoted-printable Message-Id: <4953F764-FC4E-491F-A6B7-4CAF65EAAEB7@dsl-only.net> References: <5A0ACA76-6F1D-4975-9E59-2A64BB8EFC77@dsl-only.net> <56FD9757.6040709@FreeBSD.org> <9E3033D5-F416-4B78-97C2-0A0AABF5A49E@dsl-only.net> <56FDA5F9.1090601@FreeBSD.org> <481DA341-0DFC-4AF1-AD4D-56C5388FA8E3@dsl-only.net> <56FDBAA8.5060407@FreeBSD.org> <7DEF97EC-D970-4F64-AF72-8939609A1D48@dsl-only.net> To: Bryan Drewery X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 May 2016 00:15:38 -0000 On 2016-May-27, at 4:48 PM, Bryan Drewery = wrote: > On 3/31/2016 8:33 PM, Mark Millard wrote: >> I appears that C++ needs its own override for where to find C++ = header before looking in the gcc49 specific places. >=20 > Yes, the hacks for that are builtin already. Passing C_INCLUDE_PATH = and > others may break it. When I try the experiment I'll try to remember to disable any such env = based workarounds that I currently have in place. >> These sorts of odd, hard to avoid dependencies are part of why I = asked if there was a standard/recommend assignment to use for CC/XCC: I = was hoping there was a known-good way to compile that avoided the = issues, possibly by using powerpc64-gcc tools for CC/XCC as well. >=20 > You shouldn't need to pass any extra -I/-isystem or env vars for = paths. > The problem in this thread was just the ports compiler using > /usr/local/include when not using a --sysroot. This is only in the > early phase of the build. >=20 > Mind trying this patch? I'm currently doing libc++ related build experiments for Dimitry Andric. = A successful build would end about 8 hours from now. So it will be a = while before I can get to your experiment. > = https://people.freebsd.org/~bdrewery/patches/gcc-no-local-include.patch >=20 > I assume you are using that port, if not you can apply the same change > to whichever your ports gcc came from. For the powerpc64 context I use lang/gcc49 and = devel/powerpc64-xtoolchain-gcc (so devel/powerpc64-gcc which is a 5.3 = variant that has file conflicts with lang/gcc5's 5.3). I use lang/gcc49 = instead of lang/gcc5 because of devel/powerpc64-gcc conflicting. No gcc = 4.2.1 present or built. System clang built but unused. > It removes the /usr/local/include path. It is somewhat the wrong fix = vs > "fixing the order", but the /usr/local/lib path is not in there now = and > you must use -rpath with the ports gcc anyhow. So the ports gcc is > already broken for /usr/local, it should be fully broken or fully = fixed, > not half broken to the point of breaking other things. + --with-local-prefix=3D/usr/include \ looks wrong to me. The default is not /usr/local/include but just = /usr/local . Quoting https://gcc.gnu.org/install/configure.html : --with-local-prefix=3Ddirname Specify the installation directory for local include files. The default = is /usr/local. Specify this option if you want the compiler to search = directory dirname/include for locally installed header files instead of = /usr/local/include. So your change would generate /usr/include/include for the overall = include path from what I can tell. Do you want: + --with-local-prefix=3D/usr \ instead? > I'm still just curious if it fixes the problems with "stage 3" finding > the wrong dwarf header, and if removing your own include path hacks > progresses the build further. >=20 > --=20 > Regards, > Bryan Drewery =3D=3D=3D Mark Millard markmi at dsl-only.net