Re: r273918 buildworld broke at semaphore

On Tuesday, November 11, 2014 4:22:05 pm Henry Hu wrote:
> On Tue, Nov 11, 2014 at 1:33 PM, John Baldwin <jhb_at_freebsd.org> wrote:
> 
> > On Friday, October 31, 2014 4:08:06 pm Beeblebrox wrote:
> > > First breakage in a long time. Error is:
> > >
> > > In file included from cancelpoints_sem_new.c:47:
> > > /usr/src/lib/libc/../../include/semaphore.h:41:16: error: field has
> > > incomplete type 'struct _usem2'
> > >         struct _usem2   _kern;
> > >                         ^
> > > /usr/src/lib/libc/../../include/semaphore.h:41:9: note: forward
> > declaration
> > > of 'struct _usem2'
> > >         struct _usem2   _kern;
> > >                ^
> > > cancelpoints_sem_new.c:66:33: error: use of undeclared identifier
> > > 'USEM_MAX_COUNT'
> > > _Static_assert(SEM_VALUE_MAX <= USEM_MAX_COUNT, "SEM_VALUE_MAX too
> > large");
> > >                                 ^
> > > cancelpoints_sem_new.c:335:15: warning: implicit declaration of function
> > > 'USEM_COUNT' is invalid in C99 [-Wimplicit-function-declaration]
> > >         *sval = (int)USEM_COUNT(sem->_kern._count);
> > >                      ^
> > > cancelpoints_sem_new.c:342:23: error: use of undeclared identifier
> > > 'UMTX_OP_SEM2_WAKE'
> > >         return _umtx_op(sem, UMTX_OP_SEM2_WAKE, 0, NULL, NULL);
> > >                              ^
> > > cancelpoints_sem_new.c:361:23: error: use of undeclared identifier
> > > 'UMTX_OP_SEM2_WAIT'
> > >         return _umtx_op(sem, UMTX_OP_SEM2_WAIT, 0,
> > >                              ^
> > > cancelpoints_sem_new.c:445:14: error: use of undeclared identifier
> > > 'USEM_HAS_WAITERS'
> > >         if (count & USEM_HAS_WAITERS)
> > >                     ^
> > > 1 warning and 5 errors generated.
> >
> > Seems like your tree is not fully up to date?  The changes to sem_new.c
> > were
> > committed in the same commit as the changes to sys/umtx.h.
> 
> 
> Maybe it's another problem. buildworld may be picking up umtx.h from
> /usr/include which is the old version.

'make buildworld' should always populate an include tree under /usr/obj that 
is used instead of /usr/include.  If this wasn't correct, then every change to 
add new constants, etc. to any header installed to /usr/include would fail to 
build.

-- 
John Baldwin