From owner-freebsd-stable@freebsd.org Sun Oct 16 18:34:48 2016 Return-Path: Delivered-To: freebsd-stable@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 BA2E6C14106 for ; Sun, 16 Oct 2016 18:34:48 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7FE281D16 for ; Sun, 16 Oct 2016 18:34:48 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22b.google.com with SMTP id 139so25174000itm.1 for ; Sun, 16 Oct 2016 11:34:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=BxsxLLCkxXHeUmKj+JnC6PRMpD65EoO7ZKqnPEOZPYY=; b=ZDMmvv6Fh70TnqSNTDyl86e1ebey8qifAXGkSiELmagiNKFdZQ45fnE31K3tKOrUty BjGuxubcEAXyqmCgQ45GapLnB4MyOWs2vrguA4LmdNdnuEoft4nQzuCagxAtpbKoL7f3 VPe2r6qUrNCU9DPEQ3rsRDUMntUkkaayVCdWDcDLQy6MjW5+Mr0k3stM2zR3diNcyiNl MlG1vJ56A1CtaPPevgVU3YLxdEx9Xn73VF76Qp/my+1R4hvKTIVXxhGjGKboyCUDbdZf aJ4RMpAbxZkmhWKNzfZMm37UMI+xatwsg36KON1uARXQdaKPSibYzidMQBaIOmIdnggp u1sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=BxsxLLCkxXHeUmKj+JnC6PRMpD65EoO7ZKqnPEOZPYY=; b=fhz2/V0ox1EtjyD0zlS1IveZFVNzE4KmlAcoqCQBkWm2WLFFqAYf3Mvsq4opW3TZHw 6s0sBHynY3GKED2rbFTbG9jWo0deYpHWc+rcp1/a9N0E60KkWpOU91w+m2bwetHLMzxS 4iyftJrtLHpw2QAd7WPgMZZwFUKl5g4xu24e0BDM9lROqFO9N6fYDHI+95GZYpoqVd0M dCC7gdHuIs/2RBQUoTvXn0LABu9xzYdZlToBDdlPMPWtpBSyui4wVohxh8eMbt6hiANh LIQS0cOgNIrfKxvqF8aZPssiBLOy7SfgYJvDtRLqAYWr1604cfRG4aOZknxr48kWuIPb DMeA== X-Gm-Message-State: AA6/9RkzpmYmn9C/DYOhgpc+3TsVTmI1dg5XuOXZPbEAqrcYN/LduKj08sUUSCSZ4c/3a8O2tt9iVSC5vGptHQ== X-Received: by 10.36.43.82 with SMTP id h79mr6388816ita.60.1476642887811; Sun, 16 Oct 2016 11:34:47 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.77.85 with HTTP; Sun, 16 Oct 2016 11:34:47 -0700 (PDT) X-Originating-IP: [50.253.99.174] In-Reply-To: <84890108-CB52-4B2B-B795-C650879469E9@FreeBSD.org> References: <20161016122041.e20ae504c58d4f9224eec6bf@getmail.no> <426D0291-D785-4CFE-A15D-9BE688499ACB@FreeBSD.org> <84890108-CB52-4B2B-B795-C650879469E9@FreeBSD.org> From: Warner Losh Date: Sun, 16 Oct 2016 12:34:47 -0600 X-Google-Sender-Auth: yYd3oYSdgIJpL_e2X3YE7TLRhRk Message-ID: Subject: Re: Building FreeBSD 11.0-stable on FreeBSD 10.1-stable fails To: Dimitry Andric Cc: Bryan Drewery , Torfinn Ingolfsen , FreeBSD-STABLE Mailing List Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2016 18:34:48 -0000 On Sun, Oct 16, 2016 at 12:18 PM, Dimitry Andric wrote: > On 16 Oct 2016, at 17:22, Warner Losh wrote: >> >> On Sun, Oct 16, 2016 at 5:34 AM, Dimitry Andric wrote: >>> On 16 Oct 2016, at 12:20, Torfinn Ingolfsen 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