On Sun, Oct 16, 2016 at 12:18 PM, Dimitry Andric <d...@freebsd.org> wrote:
> On 16 Oct 2016, at 17:22, Warner Losh <i...@bsdimp.com> wrote:
>> On Sun, Oct 16, 2016 at 5:34 AM, Dimitry Andric <d...@freebsd.org> wrote:
>>> On 16 Oct 2016, at 12:20, Torfinn Ingolfsen <torfinn.ingolf...@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
>>>> r...@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"
>>>> 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

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

freebsd-stable@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Reply via email to