From owner-freebsd-toolchain@freebsd.org Wed Jun 28 14:45:36 2017 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 47BD3DA3A5B for ; Wed, 28 Jun 2017 14:45:36 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-23.reflexion.net [208.70.210.23]) (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 E76347BDBC for ; Wed, 28 Jun 2017 14:45:35 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 14921 invoked from network); 28 Jun 2017 14:38:54 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 28 Jun 2017 14:38:54 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Wed, 28 Jun 2017 10:38:54 -0400 (EDT) Received: (qmail 25256 invoked from network); 28 Jun 2017 14:38:54 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 28 Jun 2017 14:38:54 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 8936BEC9004; Wed, 28 Jun 2017 07:38:53 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: lang/gcc* package builds vs. release/11.0.1/ and the future release/11.1.0 because of vm_ooffset_t and vm_pindex_t changes and how the lang/gcc* work From: Mark Millard In-Reply-To: <82A991B0-FD8B-457F-8483-D61AE5E6D6F6@pfeifer.com> Date: Wed, 28 Jun 2017 07:38:52 -0700 Cc: papowell@astart.com, FreeBSD-STABLE Mailing List , FreeBSD Toolchain , FreeBSD Ports , Pedro Giffuni Content-Transfer-Encoding: quoted-printable Message-Id: References: <6FD738D6-F163-4BC5-8E6E-A9B9F35595CD@dsl-only.net> <82A991B0-FD8B-457F-8483-D61AE5E6D6F6@pfeifer.com> To: Gerald Pfeifer X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 14:45:36 -0000 On 2017-Jun-28, at 3:21 AM, Gerald Pfeifer wrote: > I am testing a patch for gcc5-devel right now that will disable = fixincludes (or rather its fixed files) being packaged. >=20 > Should that work fine for you, I will push this back to gcc5 the = following days. >=20 > That said, the change that triggered this is what I would expect on = CURRENT, not STABLE (and hence hoped we'd have more time for this = change). >=20 > My Internet connectivity right now is only slightly above pigeon = speed, so sorry for any delays. Thanks! Some notes: A primary test is building lang/gcc5-devel under release/11.0.1 and then using it under stable/11 or some draft of release/11.1.0 . It looks like the the lang/gcc5-devel build still creates and uses the headers that go in include-fixed/ but that they are removed from $(STAGEDIR}${TARGLIB} 's tree before installation or packaging. So, if I understand right, lang/gcc5-devel itself still does use the adjusted headers to produce its own materials but when lang/gcc5-devel is used later it does not. Definitely something to be testing since it is a mix overall. Is some form of exp-like run needed that tries to force use of a release/11.0.1 built lang/gcc5-devel (-r444563) to build other things under, say, stable/11 or some draft of release/11.1.0 ? Is this odd combination even possible currently? A normal exp-run on release/11.0.1 without a system version switch being involved also seems appropriate. The same could be said of an exp-run based on a release/11.1.0 draft for both building lang/gcc5-devel and using it to build other things. I had hoped that the Linux =46rom Scratch technique of doing: sed -i 's@\./fixinc\.sh@-c true@' gcc/Makefile.in (or an equivalent) before gcc/Makefile.in is used would allow lang/gcc5-devel to use the same headers in its build that the installed compiler would then use to produce other code --by avoiding generating most of the adjusted files in the first place. But I guess that did not work out. Eventually most of the lang/gcc* 's will need whatever technique is used. Some, such as lang/gcc6-aux, need more done because of binary bootstrap materials being downloaded and used and so the build of lang/gcc6-aux gets the problem and fails before staging happens: the binary-bootstrap materials need to avoid the adjusted headers that they currently contain. =3D=3D=3D Mark Millard markmi at dsl-only.net