Date: Sun, 14 Feb 2016 15:40:56 -0800 From: Mark Millard <markmi@dsl-only.net> To: Warner Losh <imp@bsdimp.com> 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: <338854A3-DB47-4356-B63C-1901894FA1D2@dsl-only.net> In-Reply-To: <85E263E8-445F-4AA0-82E7-4CDBC28509B7@dsl-only.net> References: <A82D5D96-E9CF-48EE-B689-20AD22E44D0D@dsl-only.net> <CANCZdfqe721ksCfGYeE-TRgs_EdhjptaNBjBVG-8MHacXr%2BOJw@mail.gmail.com> <85E263E8-445F-4AA0-82E7-4CDBC28509B7@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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=3D
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.
=3D=3D=3D
Mark Millard
markmi at dsl-only.net
On 2016-Feb-14, at 12:35 PM, Mark Millard <markmi@dsl-only.net> wrote:
>=20
> On 2016-Feb-14, at 12:16 PM, Warner Losh <imp@bsdimp.com> wrote:
>>=20
>> 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.)
>>=20
>> Yes, but only though the end of the bootstrap phase.
>>=20
>> 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=3Dpowerpc =
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).
>>=20
>> /usr/src/Makefile.inc1 has the following sort of logic:
>>=20
>>> .if ${XCC:N${CCACHE_BIN}:M/*}
>> . . .
>>> .if defined(X_COMPILER_TYPE) && ${X_COMPILER_TYPE} =3D=3D gcc
>>> XCFLAGS+=3D -isystem ${WORLDTMP}/usr/include =
-L${WORLDTMP}/usr/lib
>>> XCXXFLAGS+=3D -I${WORLDTMP}/usr/include/c++/v1 -std=3Dgnu++11 =
-L${WORLDTMP}/../lib/libc++
>> . . .
>>> .else
>> . . .
>>> .endif
>>> XCFLAGS+=3D --sysroot=3D${WORLDTMP} ${BFLAGS}
>>> XCXXFLAGS+=3D --sysroot=3D${WORLDTMP} ${BFLAGS}
>>> .else
>>> .if defined(CROSS_BINUTILS_PREFIX) && =
exists(${CROSS_BINUTILS_PREFIX})
>>> BFLAGS+=3D -B${CROSS_BINUTILS_PREFIX}
>>> XCFLAGS+=3D ${BFLAGS}
>>> XCXXFLAGS+=3D ${BFLAGS}
>>> .endif
>>> .endif # ${XCC:M/*}
>>=20
>> For contexts without the -isystem and/or --sysroot in XCFLAGS . . .
>>=20
>> Is it appropriate to submit bug reports for buildworld getting =
include files from /usr/include instead of from ${WORLDTMP} or from =
/usr/src areas?
>>=20
>> 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.
>>=20
>> This tends to be noticed when something like the following. . .
>>=20
>>> # svnlite update -r295453 /usr/src
>>> # env __MAKE_CONF=3D/root/src.configs/make.conf =
SRC_ENV_CONF=3D/root/src.configs/src.conf.powerpc-gcc421.powerpc-host =
MAKEOBJDIRPREFIX=3D/usr/obj/gcc421/powerpc.powerpc make -j 6 buildworld =
buildkernel
>>=20
>> ends up with compile errors from using some older /usr/include header =
files that are no longer sufficient to allow compilation.
>>=20
>> 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+=3DSOMETHING_DIRECTING_INCLUDE_SEARCH .
>>=20
>> (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.)
>>=20
>> I expect that there are analogous points/questions for finding =
libraries.
>>=20
>> Specific examples would be most welcome.
>>=20
>> Warner=20
>=20
> I had submitted the following bug reports for the two recent examples =
that prompted my question. . .
>=20
>=20
>=20
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207147 for:
>=20
> 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
>=20
>=20
>=20
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207148 for:
>=20
> /usr/src/bin/pkill/pkill.c:353: error: 'P_KPROC' undeclared (first use =
in this function)
>=20
>=20
>=20
> 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.
>=20
> =3D=3D=3D
> Mark Millard
> markmi at dsl-only.net
>=20
>=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?338854A3-DB47-4356-B63C-1901894FA1D2>