On 2016-Feb-14, at 12:16 PM, Warner Losh <[email protected]> wrote: > > On Sun, Feb 14, 2016 at 12:21 PM, Mark Millard <[email protected]> wrote: > Is buildworld supposed to use /usr/include's area for finding files by > default? (I'm not talking of ${WORLDTMP}/usr/include but of just > /usr/include.) > > Yes, but only though the end of the bootstrap phase. > > It does use /usr/include's area for some contexts: self-hosted builds without > a special XCC full path (e.g., an implicit TARGET_ARCH=powerpc on a powerpc > host using gcc 4.2.1 without an explicit XCC assignment that also directs it > to gcc 4.2.1 via a full path). > > /usr/src/Makefile.inc1 has the following sort of logic: > > > .if ${XCC:N${CCACHE_BIN}:M/*} > . . . > > .if defined(X_COMPILER_TYPE) && ${X_COMPILER_TYPE} == gcc > > XCFLAGS+= -isystem ${WORLDTMP}/usr/include -L${WORLDTMP}/usr/lib > > XCXXFLAGS+= -I${WORLDTMP}/usr/include/c++/v1 -std=gnu++11 > > -L${WORLDTMP}/../lib/libc++ > . . . > > .else > . . . > > .endif > > XCFLAGS+= --sysroot=${WORLDTMP} ${BFLAGS} > > XCXXFLAGS+= --sysroot=${WORLDTMP} ${BFLAGS} > > .else > > .if defined(CROSS_BINUTILS_PREFIX) && exists(${CROSS_BINUTILS_PREFIX}) > > BFLAGS+= -B${CROSS_BINUTILS_PREFIX} > > XCFLAGS+= ${BFLAGS} > > XCXXFLAGS+= ${BFLAGS} > > .endif > > .endif # ${XCC:M/*} > > For contexts without the -isystem and/or --sysroot in XCFLAGS . . . > > Is it appropriate to submit bug reports for buildworld getting include files > from /usr/include instead of from ${WORLDTMP} or from /usr/src areas? > > If it is during the build everything phase, yes it is a build bug. If it is > during the bootstrap phase, then yes, it is expected we use the host, but > there's some incompatibility in bootstrapping we need to fix. > > This tends to be noticed when something like the following. . . > > > # svnlite update -r295453 /usr/src > > # env __MAKE_CONF=/root/src.configs/make.conf > > SRC_ENV_CONF=/root/src.configs/src.conf.powerpc-gcc421.powerpc-host > > MAKEOBJDIRPREFIX=/usr/obj/gcc421/powerpc.powerpc make -j 6 buildworld > > buildkernel > > ends up with compile errors from using some older /usr/include header files > that are no longer sufficient to allow compilation. > > I recently had a couple of examples where the cc command in the script output > file for the failing compiles showed no -I , no -isystem , no --sysroot , > nothing that would have allowed it to even potentially avoid /usr/include > (old file) use. The Makefile*'s involved had no > CFLAGS+=SOMETHING_DIRECTING_INCLUDE_SEARCH . > > (Some types of header changes might not stop a build but might make the build > result wrong without much explicit notification. I'd prefer to avoid such as > well.) > > I expect that there are analogous points/questions for finding libraries. > > Specific examples would be most welcome. > > Warner
I had submitted the following bug reports for the two recent examples that prompted my question. . . https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207147 for: In file included from /usr/src/lib/libmemstat/memstat_uma.c:37: /usr/include/vm/uma_int.h:310: error: field 'uz_maxaction' has incomplete type https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207148 for: /usr/src/bin/pkill/pkill.c:353: error: 'P_KPROC' undeclared (first use in this function) In both cases the /usr/include vintage file was in use after my update of /usr/src to -r295453. In both cases the "cc" command had no -I , no -sysroot , and no -isystem to direct the searching for the header file. === Mark Millard markmi at dsl-only.net _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "[email protected]"
