On Fri, Aug 11, 2006 at 02:00:16PM -0400, Richard Lowe wrote: > Gavin Maltby wrote: > >Joerg Schilling wrote: > > > >> > >>This would make OpenSolaris more stable even in the non-cross compilation > >>case. Note that OpenSolaris does use /usr/include from the host system > >>instead of using the include files that are specific to the current build > > > >Where that happens for ON it is a bug either in makefiles or in the > >build environment that control the makefiles. In most cases > >header files should be found from the proto area of the > >workspace being built (ENVCPPFLAGS1) or in the proto area > >of a fully-built parent workspace (ENVCPPFLAGS2). The latter > >are used particularly for partial builds of your workspace. > > > >There is an obscure compiler switch that can stop it automatically > >appending /usr/include to the search path. If we dig that > >up (I have it in email from a few years back if all else fails) > >then we could force compile errors for ON when it uses something > >from the host system. > > > > I like the idea, though obviously it'd have to be selective to account > for pieces that use non-ON headers.
The easiest thing to do is populate a "non-ON-build-stuff" directory, and re-point the "system include" directory to it. > I've only ever seen ON headers from the host used in the situation that > the headers are not present in the proto, generally due to not having > run make setup when using bldenv, but I think it could be a good thing > to enforce where practical. Indeed; but there have been problems like deleting a header file and not noticing that some part of the build was still using it; that occurred a few builds back, actually. Cheers, - jonathan -- Jonathan Adams, Solaris Kernel Development _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
