First off, thanks for looking into this. Build issues are no fun. :( On May 6, 2014, at 8:11 AM, Stefan Esser <se_at_freebsd.org> wrote: > Am 06.05.2014 15:18, schrieb Warner Losh: >> >> On May 6, 2014, at 7:16 AM, Warner Losh <imp_at_bsdimp.com> wrote: >> >>> >>> On May 6, 2014, at 6:39 AM, Stefan Esser <se_at_freebsd.org> wrote: >>> >>>> Am 06.05.2014 13:44, schrieb Trond Endrestøl: >>>>> On Tue, 6 May 2014 13:24+0200, Stefan Esser wrote: >>>>>> Am 06.05.2014 11:52, schrieb Stefan Esser: >>>>>>> Hi Warner, >>>>>>> >>>>>>> as already reported by Jenkins, HEAD does not build. >>>>>>> >>>>>>> Seems that this is caused by src.opts.mk missing in >>>>>>> /usr/share/mk during the cleandir phase. I guess this is >>>>>>> kind of a bootstrap issue - the definitions are looked up >>>>>>> in the installed base, not in the src tree - but did not >>>>>>> verify this assumption. >>>>>>> >>>>>>> A work-around is to manually install src.opts.mk: >>>>>>> >>>>>>> # make -C /usr/src/share/mk install >>>>>>> >>>>>>> (which might deserve an UPDATING entry). Falling back on >>>>>>> the file in the src directory might be a better solution >>>>>>> ... >>>>>>> >>>>>>> Regards, STefan >>>>>> >>>>>> Following up to my earlier mail: >>>>>> >>>>>> The diagnosis was wrong - the main Makefiles include >>>>>> src.opts.mk from the source directory. But two sub-ordinate >>>>>> Makefiles missed to include the new options file >>>>>> (sys/conf/kmod.mk and sys/modules/drm2/Makefile). >>>>>> >>>>>> I committed a fix/work-around to stop the flood of >>>>>> tinderbox messages (r265433). >>>>> >>>>> tinderbox still complains about usr.bin/bmake/Makefile.inc. >>>> >>>> Hmmm, I managed to buildworld -HEAD after this patch, but it >>>> is possible, that I had src.opts.mk installed in /usr/share/mk >>>> when I started the build. >>>> >>>> (I later deleted it, to be sure that the version in the source >>>> directory was found and used when building modules, which the >>>> commit actually fixed.) >>>> >>>> I guess the remaining problem is caused by >>>> >>>> .include "src.opts.mk" >>>> >>>> in line 3 of src/usr.bin/bmake/Makefile.inc >>>> >>>> Changing this line to read ".include <src.opts.mk>" seems to >>>> fix it on my system. >>>> >>>> --- usr.bin/bmake/Makefile.inc~ +++ usr.bin/bmake/Makefile.inc >>>> _at__at_ -1,6 +1,6 _at__at_ # $FreeBSD$ >>>> >>>> -.include "src.opts.mk" +.include <src.opts.mk> This change I think actually is right. And it needs to be an ‘sinclude’ to support the fmake upgrade path, but I need to double check that can’t be worked around in the environment. >>>> .if defined(.PARSEDIR) # make sure this is available to >>>> unit-tests/Makefile >>>> >>>> It is possible, that the build will still fail at a latter >>>> stage, though (buildworld is still running). >>>> >>>> I committed the above patch, since it gets buildworld through >>>> the bmake subdirectory at least (r265436). If buildworld fails >>>> again, then I'll commit any further missing fixes in one go. >>>> I'll know in some 20 minutes. >>> >>> What is your source system? This is absolutely the wrong change, >>> and shouldn’t be necessary at all. These changes survived a >>> universe run and a few build worlds on other systems. > > I'm on a fresh -CURRENT (built the previous day) and with sources > as of r265439. OK. My current is a bit dated, so I’ll spin up a new one. > I agree, that the change to bmake/Makefile.inc was wrong - though > it was needed to get a "make cleandir" working in that directory. Yea, I’m trying to get one that works all the time… I think I have it which should silence the tinderboxes… In hind sight, perhaps I should have pushed this in first thing this morning rather than last thing last night... >> <hit send too fast> >> >> so I’d like to know how to recreate it, since I didn’t see this in >> any of my testing over the last two weeks... > > The tinderbox builds all fail in bmake, and while I changed > Makefile.inc to fix just that kind of problem on my system, it > may have worked by accident (because of a forgotten src.opts.mk > in /usr/share/mk - it had been installed by a previous attempt > to work around these problems). The initial bootstrap of bmake, or the later build of bmake? I was able to reproduce the former, but haven’t seen the latter fail. > To recapitulate the order of events: > > 1) make buildkernel failed due to 2 missing includes of > src.opts.mk. The affected files files were: > > sys/conf/kmod.mk > sys/modules/drm2/Makefile > > Adding an .include <src.opts.mk> seems to have fixed this > problem. Maybe "src.opts.mk" would have been more correct, > but I checked without src.opts.mk in /usr/share/mk and the > file was found in src/share/mk. I’ll look at these. I might have introduced the issues after I stopped building the 75 kernels in make universe after I made it through once. My bad... > 2) tinderbox still complained about the test for MK_SHARED_TOOLCHAIN > in bmake/Makefile.inc (I deleted the mails and thus cannot > easily quote the exact error message). I tried to fix this by > changing the include syntax in bmake/Makefile.inc, but have > just reverted this change. It made buildworld complete on my > system, but tinderbox complains loudly. I’ll look at this as well... > A work-around for the second problem is to manually install > src.opts.mk in /usr/share/mk before attempting to build bmake. Yea, and we don’t really want to do that. The other workaround is mentioned in updating… Setting MAKESYSPATH. I need to make sure my testing wasn’t contaminated with this somehow. Warner
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:49 UTC