First off, thanks for looking into this. Build issues are no fun. :(

On May 6, 2014, at 8:11 AM, Stefan Esser <> wrote:

> Am 06.05.2014 15:18, schrieb Warner Losh:
>> On May 6, 2014, at 7:16 AM, Warner Losh <> wrote:
>>> On May 6, 2014, at 6:39 AM, Stefan Esser <> 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 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
>>>>>>> # 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
>>>>>> from the source directory. But two sub-ordinate
>>>>>> Makefiles missed to include the new options file
>>>>>> (sys/conf/ 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/
>>>> Hmmm, I managed to buildworld -HEAD after this patch, but it
>>>> is possible, that I had 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 ""
>>>> in line 3 of src/usr.bin/bmake/
>>>> Changing this line to read ".include <>" seems to
>>>> fix it on my system.
>>>> --- usr.bin/bmake/ +++ usr.bin/bmake/ 
>>>> @@ -1,6 +1,6 @@ # $FreeBSD$
>>>> -.include "" +.include <>

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/ 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
> to fix just that kind of problem on my system, it
> may have worked by accident (because of a forgotten
> 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
> The affected files files were:
>       sys/conf/
>       sys/modules/drm2/Makefile
>   Adding an .include <> seems to have fixed this
>   problem. Maybe "" would have been more correct,
>   but I checked without 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/ (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/, 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
> 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.


Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Reply via email to