Date: Sun, 16 Oct 2016 12:34:47 -0600 From: Warner Losh <imp@bsdimp.com> To: Dimitry Andric <dim@freebsd.org> Cc: Bryan Drewery <bdrewery@freebsd.org>, Torfinn Ingolfsen <torfinn.ingolfsen@getmail.no>, FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org> Subject: Re: Building FreeBSD 11.0-stable on FreeBSD 10.1-stable fails Message-ID: <CANCZdfqxS_XZsBJy=c5Wd%2BTqNzHOgdBoJJvgufZ5pqvDGhS%2B2g@mail.gmail.com> In-Reply-To: <84890108-CB52-4B2B-B795-C650879469E9@FreeBSD.org> References: <20161016122041.e20ae504c58d4f9224eec6bf@getmail.no> <426D0291-D785-4CFE-A15D-9BE688499ACB@FreeBSD.org> <CANCZdfr1YhbbcVbHfkMqjofHe16zHhcz%2Bi39_MvbiCm84Sje6A@mail.gmail.com> <84890108-CB52-4B2B-B795-C650879469E9@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Oct 16, 2016 at 12:18 PM, Dimitry Andric <dim@freebsd.org> wrote: > On 16 Oct 2016, at 17:22, Warner Losh <imp@bsdimp.com> wrote: >> >> On Sun, Oct 16, 2016 at 5:34 AM, Dimitry Andric <dim@freebsd.org> wrote: >>> On 16 Oct 2016, at 12:20, Torfinn Ingolfsen <torfinn.ingolfsen@getmail.no> wrote: >>>> I am trying to build FreeBSD 11.0-stable on a machine which runs: >>>> tingo@kg-v7$ uname -a >>>> FreeBSD kg-v7.kg4.no 10.1-STABLE FreeBSD 10.1-STABLE #0 r278322: Fri Feb 6 21:36:01 CET 2015 >>>> root@kg-v7.kg4.no:/usr/obj/usr/src/sys/GENERIC amd64 >>>> >>>> I have emptied /usr/src and /usr/obj and fetched the latest stable/11 via subversion: >>>> tingo@kg-v7$ egrep "^BRANCH|^REVISION" /usr/src/sys/conf/newvers.sh >>>> REVISION="11.0" >>>> BRANCH="STABLE" >>>> >>>> But building it (per the procedure in the handbook) fails at the buildworld stage. Both 'make -j5 buildworld' and 'make buildworld' fails, like this: >>>> >>>> c++: error: unable to execute command: Segmentation fault (core dumped) > ... >>> Please make sure your stable/10 is at least r286033. >> >> What's the issue this fixes? > > It fixes a possible crash in clang 3.4, which can occur if newer > versions of llvm are compiled. Unfortunately this fix only went in > after 10.3-RELEASE. > > >> Right now we have safeties in place in >> buildworld that indicate we 'support' back to 9 sometime. If that's >> not really the case, we need to fix something (either fix so we don't >> need this specific revision, or fix the Makefile to indicate we don't >> support back that far). > > The fix was also merged to stable/9 in r286035. As far as I know, we > have always required people to upgrade to the latest revision in stable > branches before attempting to hop to the next stable branch (or head). No. that's not always been the case. It hasn't been the case since Ruslan Ermilov's efforts to support from the 4.x branch point upgrades to 5, 6 and 7. We've well supported upgrading from older versions for 15 years or so. It's been documented in Makefile.inc1 for all that time, and the documented version has generally worked for much of that time. There was a policy that pre-dated this stating only tip of stable to next stable, but that policy has been found to be needlessly restrictive so people like Juniper have made sure that older -> newer builds have been working for maybe the last 5-8 years. It causes them big logistical issues to upgrade their build servers too often due to dependencies that most people don't have on non-public third-party code that doesn't gracefully upgrade. So not since the 3.x -> 4.x days has there been a requirement to upgrade to tip of stable of X-1 before building X. It's usually X-2 or X-3 and generally all the release points on the branch, or at least most of the branch. If we can't do it now because of old bugs in releases that we can't work around (which this sounds like), we'll need to fix that in the versions we allow to be correct. Generally, we've been able to work around issues, but this one sounds to be almost impossible w/o host modification. In addition to fixing the version in Makefile,inc1, we'll need to document this change from past expectations in the release notes (retroactively), in UPDATING and in the handbook. Suffice to say, this is a big problem that sadly we can only fix with documentation. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfqxS_XZsBJy=c5Wd%2BTqNzHOgdBoJJvgufZ5pqvDGhS%2B2g>