Re: HEADS UP: netatm disabling taking place shortly

Thomas-Martin Seck wrote:
> * Robert Watson <rwatson_at_freebsd.org> [gmane.os.freebsd.current]:
> 
>> On Sat, 14 Jul 2007, Doug Barton wrote:
>>
>>> This is cool stuff, thanks for your dogged persistence in eliminating GIANT 
>>> from the network stack!
>>>
>>> One tiny thing I've noticed doing a buildworld tonight, because of the way 
>>> that /usr/src/usr.bin/kdump/mkioctls works (starting at line 19) it's 
>>> necessary to remove /usr/include/netatm _before_ trying to build. You might 
>>> want to include that in any instructions you send out regarding this change 
>>> (and maybe in UPDATING). If I've missed where you've said that already, 
>>> sorry for the noise.
>> It's odd, actually -- I ran into this a couple of times earlier in preparing 
>> the patch, but didn't run into it with later versions after I redid the 
>> include things, etc.  For example, on a vanilla machine (from a couple of 
>> weeks ago) now, I don't see the problem during buildworld.  Obviously, a bit 
>> more debugging is called for.  Could you try removing the tree in /usr/obj and 
>> see if that helps?  Perhaps things are lasting between build runs...
> 
> The error is probably caused by stale includes in
> /usr/obj/usr/src/tmp/usr/include. This should only happen when one
> builds with NO_CLEAN defined.

It depends on how you're trying to build it. If you're building kdump
in /usr/src/usr.bin/kdump then you have to remove the includes from
/usr/include first. If you're doing it as part of buildworld you
either have to not use -DNO_CLEAN (I almost always do use that) or
remove them by hand from the directory you mentioned above first.

Sorry if I caused any confusion, but I thought it went without saying
that the buildworld with the new sources should be run without
-DNO_CLEAN. My typical process is to start buildworld with it, then if
it fails I build the thing that failed by hand with 'make cleandir &&
make obj && make depend && make all'. I was fairly surprised when that
didn't work in this case. I actually managed to get bit both ways on
this one. :)

I think it would be useful to mention this explicitly somewhere ...
and probably also useful to add the old stuff to the
ObsoleteFiles.inc. It can always be deleted from there later if the
thing gets locked properly. My fear is that by leaving those includes
around there is going to be confusion that could otherwise be easily
avoided.

Doug

-- 

    This .signature sanitized for your protection