buildworld fails (missing /usr/share/mk/src.opts.mk)

Tue May 6 14:28:54 UTC 2014

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 
>>>> @@ -1,6 +1,6 @@ # $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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20140506/8bfb61b5/attachment.sig>