cvs commit: src/sys/sys cdefs.h src/include nl_types.h stdio.h

Bakul Shah bakul at BitBlocks.com
Wed Feb 1 10:51:14 PST 2006


> On Wed, Feb 01, 2006 at 10:25:28AM -0800, Bakul Shah wrote:
> > > I'm actually surprised that make includes doesn't install the sys
> > > directory as well, which would pick up the new sys/cdefs.h.  Does
> > > 'make -f Makefile.inc _includes' also exhibit the same problem?
> >=20
> > The bigger question is *why* does buildworld depend on
> > /usr/include.
> 
> You have to compile native bootstrap tools (i.e. against /usr/include)
> before you can build the rest of the world with "internal" headers.
> If you don't do this bootstrap step, your buildworld won't work in all
> upgrade cases.

But look at this error message Steve Kargl posted:

===> games/fortune/strfile (obj,depend,all,install)
cc -O2 -fno-strict-aliasing -pipe  -I/usr/obj/usr/src/tmp/legacy/usr/include -c
/usr/src/games/fortune/strfile/strfile.c
In file included from /usr/src/games/fortune/strfile/strfile.c:53:
/usr/include/stdio.h:331: error: syntax error before "__format_arg"

Is /usr/games/fortune is a build tool?  Even if /usr/includes
is not consistent due to make includes, surely fortune
shouldn't care since it includes only the "internal" headers?
Internal meaning the ones in the target system.

BTW, I have seen similar things in the past few weeks while
doing buildworld and the only way to fix this was to do make
includes.

Anyway, if it is only build tools that rely on host includes,
why do you need make includes at all?  If you do, that says
that the build tools are relying on new stuff that they are
supposed to help build and install.

More generally don't the build tools need to have an even
more stable environment?


More information about the cvs-all mailing list