From owner-svn-src-all@freebsd.org Mon Mar 6 19:45:58 2017 Return-Path: Delivered-To: svn-src-all@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 841C8CFBBDC for ; Mon, 6 Mar 2017 19:45:58 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (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 4C5E71766 for ; Mon, 6 Mar 2017 19:45:58 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x229.google.com with SMTP id m27so7500592iti.1 for ; Mon, 06 Mar 2017 11:45:58 -0800 (PST) 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=SVBsO6CTEaPME61z7NWyUJfOdzQInifp3RwyFOhSYWQ=; b=M7F5UxDfsPhGtWlMQbpUWKE7Ch1F4N5zZx3RGASCgcxi7BgIEbvuXfotFNw1A9+pwq jFKa8Z0vnvglgZ1Up2N10LmLAZ+JzlsVg003o1GNNdKiuR02TbyaJpNSe4Ij9zU1msuG yWAyp4Os2aTp0xlk+Mo1hAz4r6TxZXaQNIKgzX4D7EcVinxrtFR7jqViJh/PKV/pzay1 IL5LmGN9pJcPy3ivGa5wUXvWfD1kETAywyZ+59nlZvjrg7YWK0SpfAr+52f5+zOupfUu XnnGxouSvOOMO+EBn0sQJftQE7DLgIwDeVW9qrR6SjWJlbsqQaOG2LrnOjHifJvqu7LH Ij+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=SVBsO6CTEaPME61z7NWyUJfOdzQInifp3RwyFOhSYWQ=; b=ZL+Xh5wuCvFeZyoQs+CYcrFkbaDgVmyDQbWt+sfjxShFiRJL7QmKjAEcZaJ8I5NOnb EPED7qxM+ND++9NUqniXktWqBWfAGYvjjC7g4gvuLVbngA/IgsT2UnQEpb9Zg4f1Rlb0 8tvXUyosUVC2rUM12CSLfMkXPxtn2gvFdfbuGSlh+PIMSpPrro9fv0pGjG3Ogd50yHu/ +aQLPeynxAlcsBE2fe3b6nzwm22m9qMzn+fbdZ1+bdVy+4Sv/PMQQptCz1YtCjtZH8ed 4cCi67y9/Z4KQbHbFEuN75+O9NrpNKcDNYsmSq3MNggLCp6yCmmI/wI71fCa1apKpCsd r9NA== X-Gm-Message-State: AMke39liX/5azqGxHU+5fzcMrddlgsavuRLyB88XqAPzw33IqGvDYlI4d6TTW8lNCvcqtFr6x1d8qsV7wQ4IwA== X-Received: by 10.36.212.129 with SMTP id x123mr9131151itg.103.1488829557504; Mon, 06 Mar 2017 11:45:57 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.134.129 with HTTP; Mon, 6 Mar 2017 11:45:57 -0800 (PST) X-Originating-IP: [69.53.245.200] In-Reply-To: <1488828735.18764.43.camel@freebsd.org> References: <201703061915.v26JFSSd089794@pdx.rh.CN85.dnsmgr.net> <1488828735.18764.43.camel@freebsd.org> From: Warner Losh Date: Mon, 6 Mar 2017 12:45:57 -0700 X-Google-Sender-Auth: 4aUeShEpjjV8cQbIH2fIqjYQqh0 Message-ID: Subject: Re: svn commit: r314709 - head To: Ian Lepore Cc: rgrimes@freebsd.org, Bryan Drewery , src-committers , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 19:45:58 -0000 On Mon, Mar 6, 2017 at 12:32 PM, Ian Lepore wrote: > On Mon, 2017-03-06 at 11:15 -0800, Rodney W. Grimes wrote: >> [ Charset ISO-8859-1 unsupported, converting... ] >> > >> > On Mon, 2017-03-06 at 10:32 -0800, Rodney W. Grimes wrote: >> > > >> > > [ Charset ISO-8859-1 unsupported, converting... ] >> > > > >> > > > >> > > > On Sun, 2017-03-05 at 19:12 -0800, Bryan Drewery wrote: >> > > > > >> > > > > >> > > > > On 3/5/17 3:41 PM, Warner Losh wrote: >> > > > > > >> > > > > > >> > > > > > >> > > > > > On Sun, Mar 5, 2017 at 2:16 PM, Bryan Drewery > > > > > > ebsd >> > > > > > .org >> > > > > > > >> > > > > > > >> > > > > > > wrote: >> > > > > > > >> > > > > > > Author: bdrewery >> > > > > > > Date: Sun Mar??5 21:16:50 2017 >> > > > > > > New Revision: 314709 >> > > > > > > URL: https://svnweb.freebsd.org/changeset/base/314709 >> > > > > > > >> > > > > > > Log: >> > > > > > > ? Fix bootstrapping mtree after r313404 for older >> > > > > > > systems. >> > > > > > > >> > > > > > > ? r313404 made libnetbsd require sha384.h from >> > > > > > > libmd.??Libmd >> > > > > > > added it in >> > > > > > > ? r292782.??Update BOOTSTRAPPING to account for this. >> > > > > > > >> > > > > > > ? Reported by:??bde >> > > > > > > ? Reviewed by:??ngie >> > > > > > > >> > > > > > > Modified: >> > > > > > > ? head/Makefile.inc1 >> > > > > > > >> > > > > > > Modified: head/Makefile.inc1 >> > > > > > > ========================================================= >> > > > > > > ==== >> > > > > > > ==== >> > > > > > > ============= >> > > > > > > --- head/Makefile.inc1??Sun Mar??5 19:56:20 >> > > > > > > 2017????????(r314708) >> > > > > > > +++ head/Makefile.inc1??Sun Mar??5 21:16:50 >> > > > > > > 2017????????(r314709) >> > > > > > > @@ -1618,10 +1618,12 @@ ${_bt}-usr.bin/m4: ${_bt}- >> > > > > > > lib/libopenbsd >> > > > > > > ?${_bt}-usr.bin/lex: ${_bt}-usr.bin/m4 >> > > > > > > ?.endif >> > > > > > > >> > > > > > > -.if ${BOOTSTRAPPING} < 1000026 >> > > > > > > -_nmtree=???????lib/libnetbsd \ >> > > > > > I've been trying to document the bootstrapping stuff inline >> > > > > > like >> > > > > > >> > > > > > # r313404 made libnetbsd require libmd >> > > > > Definitely.??I forgot about that.??I think my change is >> > > > > incomplete >> > > > > and >> > > > > need to chase down a 2nd failure report.??I'll add the >> > > > > comment >> > > > > once >> > > > > that >> > > > > is figured out. >> > > > > >> > > > I tracked this down to the fact that the prototype >> > > > >> > > > ? char * MD5FileChunk(const char *, char *, off_t, off_t); >> > > > >> > > > does not exist in /usr/include/sys/md5.h on older systems. ?I >> > > > don't >> > > > see >> > > > any straightforward way to declare that a header file from the >> > > > /usr/include hierarchy is a bootstrap item that needs a newer >> > > > version >> > > > from the source tree being compiled. ?It looks like such a >> > > > header >> > > > would >> > > > have to go into the obj/.../tmp/legacy/usr/include to get used >> > > > in >> > > > the >> > > > boostrap compile, I just don't see how you get a file installed >> > > > there >> > > > early enough in bootstrap. >> > > One way around this is to use the old concept of /usr/include >> > > symlinks >> > > into the src tree, not sure if you can still do that or not, but >> > > something like >> > > (cd /usr/src/include; make install SHARED=symlinks) >> > > >> > > A bootstrapping regresssion test I use to run was to rm -r >> > > /usr/include/* >> > > before a buildworld run, that would find these issues so they >> > > could >> > > be fixed before they become forgotten. >> > > ? >> > Making my live 10-stable system's /usr/include have symlinks into a >> > 11- >> > or 12- source tree is just not an option in any way. ?The first >> > question would be "which source tree" because I have like a dozen >> > of >> > them, not a single one of them rooted at /usr/src (which is an >> > empty >> > dir). >> I dont know that the support of CUrrent -2 building -current with >> a bootstraping include issue is ever going to be workable. You >> could try to build a proper include tree someplace to use, this >> can be done with >> (cd; usr/src/include; make install DESTDIR=/my/new/tree) This >> well not touch your /usr/include, but give you a proper include tree, >> now the work is to get buildworld to use that include tree. >> >> If buildworld has degnerated to using stuff out of /usr/include >> that also needs to be fixed ASAP. >> >> > >> > >> > This can't be the first time in 30+ years that system header files >> > had >> > to participate in the process of bootstrapping early build tools, >> > but I >> > don't see any machinery in Makefile.inc1 for dealing with it. >> Happens often, hence why I had that regression test. But >> bootstrapping >> on Current-2 has never been supported and probably never well be >> supported. > > I'm aware that we officially only support building from current-1, but > we've worked hard to do much better than that for many years. The official line is that committers are only required to test for current-1, but that if interested parties want to support and maintain more then that's permitted. Since approximately FreeBSD 6.x, there's been a series of interested parties that have kept the build going for current-2 (and in some cases current -3 or -4). With the switch to clang this has become harder for values > 2. It has been well maintained for 15-odd years. > The only time I can think of it breaking in the last 10-12 years was > late in the 10-current cycle we reached a point where I could no longer > build 10-current on an 8-stable system. That was a special case due to > the cutover from gcc to clang and all the related changes. (Even with > that, I had it "almost working" but decided not to finish it and commit > all the changes involved because they would have just gotten in the way > of other modernization going on in the build system). Yes. This has been supported for a long time. > The reality is, a lot of people rely on building current from current-2 > systems for a variety of reasons, and it's worth putting some effort > into supporting that. Yes. If somebody supports it, we'll keep the version checks in Makefile.inc1 liberal. There's many parties that have wanted this over the years because they have had older build farms that need to build -current. I know this because I negotiated the original peace treaty between two committers back in the FreeBSD 5.x days and have babysat it through a series of maintainers. Warner