svn commit: r259730 - in head: gnu/lib/csu gnu/lib/libgcc gnu/lib/libstdc++ gnu/lib/libsupc++ lib/atf/libatf-c/tests share/mk sys/conf tools/tools/ath/athstats tools/tools/net80211/wlanstats usr.bi...

[Bruce Evans]

On Thu, 9 Jan 2014, Dimitry Andric wrote:

> On 09 Jan 2014, at 16:02, Ian Lepore <ian at freebsd.org> wrote:
> ...
>> At r259730:
>>
>> cc  -c -O -pipe  -std=c99 -g -Wall -Wredundant-decls -Wnested-externs
>> -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline
>> -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions
>> -Wmissing-include-dirs -fdiagnostics-show-option
>> -Wno-error-tautological-compare -Wno-error-empty-body
>> -Wno-error-parentheses-equality  -nostdinc  -I.
>> -I/local/build/staging/freebsd/imx53/src/sys
>> -I/local/build/staging/freebsd/imx53/src/sys/contrib/altq
>> -I/local/build/staging/freebsd/imx53/src/sys/contrib/libfdt -D_KERNEL
>> -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h  -funwind-tables
>> -ffreestanding
>> -Werror  /local/build/staging/freebsd/imx53/src/sys/arm/arm/trap.c
>>
>> The difference is that the -mllvm and -arm-enable-ehabi flags are
>> missing.
>
> Aha, this was a nasty mistake, sorry.  The main kernel builds do not
> include bsd.sys.mk, so CFLAGS.clang and CFLAGS.gcc do not work there at
> the moment.  Fixed in r260494.

It is a bug for kernel builds to include anything in /usr/share/mk, since
this gives a dependency on the host environment.  This bug is very old,
but not too bad for files that should rarely change, e.g., sys.mk.  It it
is very bad for critical variations of CFLAGS.

The old bug has been expanded exponentially by namespace pollution in
environment files.  Old versions of conf/*.mk have only the following
includes:

     kern.post.mk:.include "kern.mk"
     kmod.mk:.include <bsd.init.mk>
     kmod.mk:.include <bsd.links.mk>
     kmod.mk:.include <bsd.dep.mk>
     kmod.mk:.include <bsd.obj.mk>
     kmod.mk:.include "kern.mk"

This shows that the old bug was only in kmod.mk and in nested pollution
in sys.mk.  It used to be in kern.post.mk, when that included bsd.kern.mk
instead of kern.mk.  This was fixed for new sources by moving bsd.kern.mk
to kern.mk in the kernel source tree, but collaterally enlarged for old
sources by removing bsd.kern.mk from the host source tree (thus, old
kernel sources no longer compiled with new hosts, even if nothing in
*kern.mk changed).

The other includes here shouldn't cause any problems since they shouldn't
do anything that depends on the host environment including the compiler.

conf/*.mk now has the following includes:

     kern.post.mk:.include "kern.mk"
     kern.pre.mk:.include <bsd.own.mk>
     kern.pre.mk:.include <bsd.compiler.mk>
     kmod.mk:.include <bsd.init.mk>
     kmod.mk:.include <bsd.compiler.mk>
     kmod.mk:.include <bsd.links.mk>
     kmod.mk:.include <bsd.dep.mk>
     kmod.mk:.include <bsd.obj.mk>
     kmod.mk:.include "kern.mk"

bsd.sys.mk still isn't explicitly here.  For modules, it is included
by bsd.kmod.mk.  The layering for *kmod.mk is backwards:

- modules Makefiles include bsd.kmod.mk from the host environment
- bsd.kmod.mk guesses the system directory and includes conf/kmod.mk
   from there
- conf/kmod.mk then includes other files from the host environment,
   as above
- bsd.kmod.mk then includes bsd.sys.mk from the host environment.
   This bug is old.

I think you just copied the bug from bsd.kmod.mk so that it affects
kernel builds too.

Bruce