From owner-freebsd-toolchain@freebsd.org Sat May 28 21:30:14 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 6CE02B4E490 for ; Sat, 28 May 2016 21:30:14 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-190.reflexion.net [208.70.211.190]) (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 26EAB1CAD for ; Sat, 28 May 2016 21:30:13 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 31297 invoked from network); 28 May 2016 21:30:13 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 28 May 2016 21:30:13 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Sat, 28 May 2016 17:30:17 -0400 (EDT) Received: (qmail 10773 invoked from network); 28 May 2016 21:30:16 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 28 May 2016 21:30:16 -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 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 35AA8B1E001; Sat, 28 May 2016 14:30:07 -0700 (PDT) Content-Type: text/plain; charset=us-ascii 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: Sat, 28 May 2016 14:30:10 -0700 Cc: Bryan Drewery , FreeBSD Current , FreeBSD Toolchain , FreeBSD PowerPC ML , Gerald Pfeifer , Warner Losh , Dimitry Andric Content-Transfer-Encoding: quoted-printable Message-Id: 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> <4953F764-FC4E-491F-A6B7-4CAF65EAAEB7@dsl-only.net> <70a54660-775d-c12c-b991-507d26ce1342@FreeBSD.org> <72F5F9FD-5854-455D-8844-C4E1887DCE9F@dsl-only.net> <0FA52C68-43C4-489D-9EB2-2339C2B812F5@dsl-only.net> <068D322F-E46F-4FD8-8DA0-BD7D17FD2A06@dsl-only.net> To: Adrian Chadd 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 21:30:14 -0000 On 2016-May-28, at 12:03 PM, Adrian Chadd = wrote: > [snip] >=20 > hi, >=20 > please don't patch the ports compiler assumptions about things like > this. We should be targeting external toolchains on OSes (eg macosx) > where it may already generate freebsd binaries and as such we should > be calling the compiler/linker with all the flags it needs. >=20 > Having a patched compiler default for mips made things way, way harder > than it needed to be. >=20 >=20 >=20 > -adrian Are there specific technical examples of specific lessons learned from = the "patched compiler default for mips" context? Is there an intent to use /usr/src/. . . materials for = buildworld/buildkernel and the like from a non-FreeBSD context? Are = there examples? Currently I'm just providing evidence that some FreeBSD committers have = requested. I'm not a committer for FreeBSD or for upstream and will not = be making any FreeBSD system or ports changes outside my personal = context. I'm no direct risk to FreeBSD. So your note is more for the = folks having me cross check xtoolchain and related behavior than for me. Notes on my context. . . (stop reading if you do not care) Unfortunately powerpc64 and powerpc still can not be clang based overall = for buildworld/buildkernel. I will say that in my use of devel/powerpc64-xtoolchain-gcc (and so = devel/powerpc64-gcc ) to have a libc++ based FreeBSD on powerpc64 I've = always had to have some form of work around to avoid /usr/local/include = causing buildworld failures from use of the wrong files for buildworld = purposes. I have either: A) temporarily renamed files below /usr/local/include/ to avoid them = being used (or otherwise blocked /usr/local/include access) or B) used C_INCLUDE_PATH and CPLUS_INCLUDE_PATH to cause the C/C++ = compiles to look below /usr/include/ before looking below = /usr/local/include/ . (I've also experimented with extra -I's and the = like.) So far I've not used devel/powerpc64-gcc to build ports under FreeBSD. = So far I've only built ports from a self-hosted context (no cross-built = ports). So I tend to use something like lang/gcc49 to build ports. I'm = not likely to adopt a technique for building the likes of lang/gcc49 = that messes up using it to build ports. I normally self-host buildworld/buildkernel on a powerpc64 FreeBSD = context, an odd use of devel/powerpc64-gcc . But I have at times also = cross-built from an amd64 FreeBSD context and it also can have the = "wrong files for buildworld" problem for /usr/local/include/ in FreeBSD. I've never tried buildworld/buildkernel from a non-FreeBSD context and = so have never built devel/powerpc64-gcc or anything like its = configuration outside FreeBSD. =3D=3D=3D Mark Millard markmi at dsl-only.net