Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 14 Feb 2016 13:16:58 -0700
From:      Warner Losh <imp@bsdimp.com>
To:        Mark Millard <markmi@dsl-only.net>
Cc:        FreeBSD Toolchain <freebsd-toolchain@freebsd.org>,  FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>
Subject:   Re: /usr/src/Makefile.inc1 vs. buildworld finding include files: a problem for some contexts?
Message-ID:  <CANCZdfqe721ksCfGYeE-TRgs_EdhjptaNBjBVG-8MHacXr%2BOJw@mail.gmail.com>
In-Reply-To: <A82D5D96-E9CF-48EE-B689-20AD22E44D0D@dsl-only.net>
References:  <A82D5D96-E9CF-48EE-B689-20AD22E44D0D@dsl-only.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Feb 14, 2016 at 12:21 PM, Mark Millard <markmi@dsl-only.net> 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfqe721ksCfGYeE-TRgs_EdhjptaNBjBVG-8MHacXr%2BOJw>