From owner-svn-src-head@FreeBSD.ORG Thu May 8 02:20:18 2014 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from hub.FreeBSD.org (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1E31A5AE; Thu, 8 May 2014 02:20:17 +0000 (UTC) Date: Thu, 8 May 2014 18:20:02 -0400 From: Glen Barber To: Warner Losh Subject: Re: svn commit: r265581 - in head: . share/mk Message-ID: <20140508222002.GD1212@hub.FreeBSD.org> References: <201405071815.s47IF3t1010953@svn.freebsd.org> <20140508215720.GB1212@hub.FreeBSD.org> <20140508220435.GC1212@hub.FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="at6+YcpfzWZg/htY" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event User-Agent: Mutt/1.5.23 (2014-03-12) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers , Warner Losh X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 02:20:18 -0000 --at6+YcpfzWZg/htY Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 07, 2014 at 07:09:05PM -0700, Warner Losh wrote: >=20 > On May 8, 2014, at 3:04 PM, Glen Barber wrote: >=20 > > On Thu, May 08, 2014 at 05:57:20PM -0400, Glen Barber wrote: > >> On Wed, May 07, 2014 at 06:15:03PM +0000, Warner Losh wrote: > >>> Author: imp > >>> Date: Wed May 7 18:15:02 2014 > >>> New Revision: 265581 > >>> URL: http://svnweb.freebsd.org/changeset/base/265581 > >>>=20 > >>> Log: > >>> bsd.compiler.mk was implicitly included by bsd.own.mk in historical > >>> versions. With its movement to src.opts.mk, bsd.prog.mk was testing > >>> COMPILER_TYPE without including the bsd.compiler.mk anymore. In the > >>> source tree, this caused no problems, for reasons that aren't clear, > >>> but does cause problems outside of the source tree. Allow > >>> bsd.compiler.mk to be included multiple times safely, and always > >>> include bsd.compiler.mk at the top of bsd.prog.mk. Resist the urge to > >>> put it in bsd.init.mk, since that would reintroduce the implicit > >>> include. > >>>=20 > >>> Modified: > >>> head/UPDATING > >>> head/share/mk/bsd.compiler.mk > >>> head/share/mk/bsd.prog.mk > >>>=20 > >>=20 > >> Something here is breaking head/ release builds. I don't know if it is > >> this exact change set or not. > >>=20 > >> -------------------------------------------------------------- > >>>>> Kernel build for GENERIC completed on Thu May 8 01:47:57 UTC 2014 > >> -------------------------------------------------------------- > >> make: "/usr/share/mk/bsd.obj.mk" line 43: Could not find bsd.own.mk > >> make: "/usr/share/mk/bsd.init.mk" line 15: Could not find bsd.own.mk > >> make: Fatal errors encountered -- cannot continue > >> make: stopped in /usr/src/release > >>=20 > >=20 > > The revision I'm building against is r265621, for what it is worth. >=20 > OK. That=E2=80=99s a weird error. I haven=E2=80=99t deleted bsd.own.mk... >=20 > Any chance you can do some bisection to see if there=E2=80=99s a specific > change you can narrow this down to? But /usr/share/mk suggests > there=E2=80=99s some host contamination going on, which implies needing to > have a synchronized host environment (I can=E2=80=99t recall if make rele= ase > is fully virtualized or not). >=20 > But before all that, can you confirm you have a /usr/share/mk/bsd.own.mk? >=20 Ugh... This is the problem... root@grind:/releng/11-amd64-GENERIC-snap # ll usr/share/mk/bsd.own.mk ls: usr/share/mk/bsd.own.mk: No such file or directory This doesn't make any sense to me though, unless I misunderstand a prior change here. The host does the buildworld in /releng/11-amd64-GENERIC-snap/usr/src with MAKEOBJDIRPREFIX set to a non-default location, and installworld from that. In this specific case, the build was done as an "upgrade" build, not "clean" build (meaning, to seed the build chroot for a clean release build). I tend to alternate if MAKEOBJDIR is pristine every other week to try to capture cases where we expect "just 'rm -rf /usr/obj'" as a "fix" for problems. Glen --at6+YcpfzWZg/htY Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCAAGBQJTbAMSAAoJELls3eqvi17Q2LQQALulu/tsEiUe/SAE/DDLFKth 23wXT0lWQFQ2ythuPG4q/wW/uwaCe8aOzqzFz2s4xpTREcg5P47lJL3JG8y5swZr dviunsdLJ614fzHAa6ceW6dXcDt2yF8X0iVvW97pS7zjzQSeVuXepMZtYzP27DXl k6v6WwPqPR7GxRwJbb3Co6wj3TMTuDcVRNUuEQdyPlmXsOPP0sxRRwEUYddPFlss EeelZNykcx/dBS42G4BFFNPir02kKZfwvftMbklOnhYIlOFHBZdm8p82WhTn99Mh BgB+NqkfFtZmhHZaI5IBk5J9Vgy4CJVinxDLdenXENspMssMdPAn06KQw7EziLIe r312UiYMgxs587cdXIOEby7daIZ5GUdhqZgRXbfsXRU95hTmNhJqJIzIFyHXL4eu LEePeILQK4RsmOtEHdp5Nzi+/oQ6c1ne43WNZpjaGkrBrtKUAjo+9Zv7iCOrQHFK NH+TGoVUDLvkFK5EfilO+cWp1CgEmQFhn5ej43jK5QCVZjrWr0+we/mMDZ2gaUyh YrAiN/nqEGnSRKSeNdzgQfF0gmKVU1eS4NNT9IuRPTJb+5tO30kM6Fq9bYFgJJt6 QbzHT6xPXZRadZ7BB3BZ299lELfTSwrBLsPrqOKr2Y5he83cd3O6z4dqQ97q3QvI iQ/yIRVB4jFjJefSVevf =IfJW -----END PGP SIGNATURE----- --at6+YcpfzWZg/htY--