On Tue, Aug 21, 2018 at 7:49 AM, Warner Losh <imp_at_bsdimp.com> wrote: > > > On Tue, Aug 21, 2018 at 12:38 AM, John Baldwin <jhb_at_freebsd.org> wrote: > >> On 8/20/18 9:00 PM, O. Hartmann wrote: >> > -----BEGIN PGP SIGNED MESSAGE----- >> > Hash: SHA512 >> > >> > Am Mon, 20 Aug 2018 21:24:21 +0200 >> > "O. Hartmann" <ohartmann_at_walstatt.org> schrieb: >> > >> >> -----BEGIN PGP SIGNED MESSAGE----- >> >> Hash: SHA512 >> >> >> >> Building NanoBSD world on CURRENT r338113 fails due to: >> >> >> >> [...] >> >> cd /pool/sources/CURRENT/src/rescue/rescue/../../sbin/gbde && >> MK_TESTS=no >> >> UPDATE_DEPENDFILE=no _RECURSING_CRUNCH=1 >> >> MAKEOBJDIRPREFIX=/pool/nanobsd/amd64/ALERICH_amd64/pool/ >> sources/CURRENT/src/amd64.amd64/rescue/rescue >> >> make MK_AUTO_OBJ=no DIRPRFX=rescue/rescue/gbde/ -DRESCUE >> CRUNCH_CFLAGS=-DRESCUE >> >> MK_AUTO_OBJ=no obj make[5]: "/pool/sources/CURRENT/src/too >> ls/build/mk/Makefile.boot" >> >> line 18: Do not include ${SRCTOP}/sys when building bootstrap tools. >> Copy the header to >> >> ${WORLDTMP}/legacy in tools/build/Makefile instead. Error was caused >> by Makefile >> >> in /pool/sources/CURRENT/src/sbin/gbde *** [obj_crunchdir_gbde] Error >> code 1 >> >> >> >> make[4]: stopped in /pool/sources/CURRENT/src/rescue/rescue >> >> [...] >> >> >> >> >> >> This problem occured during today's source updates since I was able to >> build the NanoBSD >> >> image I intend to build yesterday ~ r338060. >> >> >> >> What is going wrong? >> > >> > It seems the problem has been introduced after r338095, since r338095 >> builds ok, while >> > r338096 doesn't. >> >> 338096 added this check to catch a kind of error in our Makefiles. Alex >> (cc'd) can >> help with figuring out what the error is. >> > > Except we're not building anything, we're making obj in rescue... It > looks like a false positive... > weird, I'm dying elsewhere. You can recreate this with cd tools/tools/nanobsd/embedded sh -c ../nanobsd.sh -c qemu-amd64-uefi.cfg it dies in mkimg. We have LOCAL_XTOOL_DIRS=usr.bin/mkimg so it's building in stage 3. It's likely because of CFLAGS+=-I${SRCTOP}/sys/sys/disk which is 100% legit always by design, so the test in this case is a false positive and must be relaxed. I'm guessing that the rescue case above is similar: we're building an different tool early. WarnerReceived on Tue Aug 21 2018 - 12:12:03 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:17 UTC