A top post as I figured out what is going on: My original src.conf had a bad "optimization" where I had been thinking that since I had a working compiler that was not being updated with new source code that I could avoid the time to rebuild it during the bootstrap:
WITHOUT_GCC_BOOTSTRAP= But this makes the default include/library paths wrong for buildworld and the like and so requires them to be enforced on the command line. The build environment is not set up to automatically do that in such cases. So I had wondered out of bounds. === Mark Millard markmi at dsl-only.net On 2016-Feb-14, at 12:35 PM, Mark Millard <[email protected]> wrote: > > 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]"
