sounds like we need to pass HOSTCC=$(tc-getBUILD_CC) in the kernel eclass.  and maybe some other HOST vars.

and it seems like there might be compiler flag settings bleeding between target & host in the kernel build.

CC and $(tc-getBUILD_CC) are both set to x86_64-cros-linux-gnu-gcc, so setting HOSTCC does not make a difference.

CFLAGS is passing the "-clang-syntax" option. Setting HOSTCFLAGS does not help; "-clang-syntax" still makes it into the host build. Clearing CFLAGS causes the build to pass.

HOSTCC and HOSTCFLAGS are not defined as valid kernel build options. It appears that CFLAGS is used for tools builds. For whatever reason, the gcc front-end script does not remove "-clang-syntax" from the options actually passed to the compiler.

BUILD_CC should *not* be set to x86_64-cros-linux-gnu-gcc.  are you sure about that ?  it should be x86_64-pc-linux-gnu-{gcc,clang}.  note "cros" vs "pc".

if the kernel build is using CFLAGS (meant for building the kernel objects) for host tools (for stuff under tools/), the kernel build is broken and needs adjusting.

@vapier: The kernel documentation doesn't say anything about CFLAGS. It talks about KCFLAGS, CFLAGS_KERNEL, and CFLAGS_MODULE. In reality, CFLAGS is widely used for building tools.

Do you have some reference suggesting that CFLAGS is supposed to be used for building kernel objects ? I want to start an upstream discussion about the subject, but I can not just make up a claim about the supposed use of CFLAGS without supporting documentation.

I'll check $(tc-getBUILD_CC) again after I have my system back in buildable state. Maybe I was misreading the output.

Something doesn't add up with CFLAGS. A kernel build with "CFLAGS=-junk make ..." or "make CFLAGS=-junk ..." works just fine unless CONFIG_STACK_VALIDATION is enabled. If CONFIG_STACK_VALIDATION is enabled, the build fails as before, only now gcc complains that it doesn't know about "-junk".

In other words, whatever we are currently passing to the kernel build with CFLAGS is not used.

Side note: CC isn't used either. "CC=junk make ..." works just fine (again unless CONFIG_STACK_VALIDATION is enabled). "make CC=junk ..." fails, suggesting that CC is used internally.

#4: You are right.
CC=x86_64-cros-linux-gnu-gcc BUILDCC=x86_64-pc-linux-gnu-gcc

I tried passing the existing CFLAGS as KCFLAGS, but that causes a build failure in a networking driver.

https://chromium-review.googlesource.com/c/chromiumos/overlays/chromiumos-overlay/+/677126

i haven't looked at the exact build settings that the kernel is using. they could be using their own naming conventions. but the fundamentals don't change. the ebuild environment settings are:
- CBUILD: tuole used for build time tools that only run on the sdk and don't get installed
- CHOST: tuple used for host code (where "host" is the chromebook/DUT/etc).
- BUILD_CC: compiler used for build tools
- BUILD_CFLAGS/BUILD_CPPFLAGS/BUILD_LDFLAGS: compiler settings used to compile build tools
- CC/CFLAGS/CPPFLAGS/LDFLAGS: compiler settings used to compile host code (i.e. the kernel itself)

the BUILD_xxx settings aren't usually exported by default. that's why we have helpers in the toolchain-funcs eclass. they also aren't 100% standard names ... some projects use XX_FOR_BUILD or HOSTXX or some other variant. we had to pick something in Gentoo.

on the other hand, the host compiler settings are standard in the larger build world.

so it's up to the kernel eclass to merge the environment names that I defined above with whatever random names the kconfig files are using. if the kernel build is mixing host and build settings, then it's broken and needs to be fixed. filtering flags is never the answer here (like that CL is doing).

#9: The flag filtered here is -clang-syntax. That same flag is filtered out in other packages as well, using the same filter function. I am not sure I understand what you are suggesting. Are you saying that the flag should never be set in the first place ? If not, what exactly do you suggest we should do with it ?

the flag filtering done in other packages is due to them not being clang clean, not because they're wrongly mixing flags.  in this case, it's because the kernel build is wrongly mixing compiler settings.

you need to figure out what tools are being built here (looks like build tools), and what toolchain settings are being passed to it, and make sure that only BUILD_xxx settings are the ones used.

Sorry, you lost me. The flags passed are CFLAGS. What does this have to do with BUILD_xxx ? Are you saying the kernel should not use CFLAGS for building objtool ? What compiler flags do you think the kernel is mixing ? We are passing CFLAGS, which the kernel build uses to build its host (build) tools. Seems perfectly fine to me. What am I missing ? You seem to say that the kernel should use CFLAGS for the kernel (target) build itself, but the kernel documentation says clearly that it expects KCFLAGS for that. So the kernel expects and uses KCFLAGS for kernel (target) compilations, and CFLAGS for host (build/tool) compilations. That seems to be well defined to me. What else do you expect it to do ?

Also, where is BUILD_CC/BUILD_CFLAGS/BUILD_CPPFLAGS/BUILD_LDFLAGS coming into the picture ? Those are not defined or used anywhere in the kernel. Are you saying that the ebuild should pass BUILD_CFLAGS as CFLAGS to kernel builds ?

i outlined the standard environment variables in comment #9 and how they should be used.  you'll have to figure out how to map them to the set of variables used by the kernel build.  if the kernel has opted to use different names, then it's the kernel eclass's job to remap.

throwing flags out like that CL is ignoring the problem, not fixing it.

#13: Ok, I understand that to mean that it is acceptable to remap CFLAGS as needed, presumably to BUILD_CFLAGS. I'll give that a try.

> the flag filtering done in other packages is due to them not being clang clean

In <http://crosreview.com/677126>, the filtering is being done because the kernel is not (necessarily) clang clean.

At the moment some versions of the kernel are clang clean (due to mka@'s work) and some are not.  For ones that are not clang clean we need the filtering.

We can have a discussion about whether or not our ebuild is mixing up how to pass kernel vs. host compiler flags, but I'm confused about your statement that adding "filter_clang_syntax" after the line "cros_use_gcc" is wrong.  We just told it to use gcc so we should remove the clang bits, right?

comment #0 says:
> gcc.real: error: unrecognized command line option '-clang-syntax'

that is *not* a matter of not being clang clean, that's entirely because the kernel build settings are wrong.  hence filtering flags to get past that error is incorrect.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/e4734c281ee96e562cdd316b34577a713139e681

commit e4734c281ee96e562cdd316b34577a713139e681
Author: Douglas Anderson <dianders@chromium.org>
Date: Thu Oct 05 07:34:13 2017

cros-kernel2: Unset CFLAGS

In general the kernel doesn't expect CFLAGS to be set.  As described
in the text of this change:

The kernel doesn't use CFLAGS and doesn't expect it to be passed in.
Let's be explicit that it won't do anything by unsetting CFLAGS.

In general the kernel manages its own tools flags and doesn't expect
someone external to pass flags in unless those flags have been very
specifically tailored to interact well with the kernel Makefiles.  In
that case we pass in flags with KCFLAGS which is documented to be not
a full set of flags but as "additional" flags. In general the kernel
Makefiles carefully adjust their flags in various sub-directories to
get the needed result.  The kernel has CONFIG_ options for adjusting
compiler flags and self-adjusts itself depending on whether it detects
clang or not.

NOTE: Right now, due to what's probably a bug, having CFLAGS set when
you compile the kernel actually _does_ affect something.  If you have
the right set of options then the kernel's Makefile will build stuff
from the tools/ Makefile.  In that particular case the kernel actually
uses CFLAGS for building host tools.  We should probably fix that in
the kernel itself so that when it calls into tools/ it passes
HOSTCFLAGS (which the main kernel Makefile uses) in as CFLAGS (which
the tools Makefiles use).

BUG= chromium:767565 
TEST=Compile a bunch of kernels

Change-Id: If695dbd0b3eb9015bf4806de8818c7512e649026
Reviewed-on: https://chromium-review.googlesource.com/696185
Commit-Ready: Douglas Anderson <dianders@chromium.org>
Tested-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>

[modify] https://crrev.com/e4734c281ee96e562cdd316b34577a713139e681/sys-kernel/chromeos-kernel-3_8/chromeos-kernel-3_8-9999.ebuild
[modify] https://crrev.com/e4734c281ee96e562cdd316b34577a713139e681/sys-kernel/chromeos-kernel-4_4/chromeos-kernel-4_4-9999.ebuild
[modify] https://crrev.com/e4734c281ee96e562cdd316b34577a713139e681/sys-kernel/chromeos-kernel-3_18/chromeos-kernel-3_18-9999.ebuild
[modify] https://crrev.com/e4734c281ee96e562cdd316b34577a713139e681/eclass/cros-kernel2.eclass
[modify] https://crrev.com/e4734c281ee96e562cdd316b34577a713139e681/sys-kernel/chromeos-kernel-3_14/chromeos-kernel-3_14-9999.ebuild
[modify] https://crrev.com/e4734c281ee96e562cdd316b34577a713139e681/sys-kernel/chromeos-kernel-4_12/chromeos-kernel-4_12-9999.ebuild
[modify] https://crrev.com/e4734c281ee96e562cdd316b34577a713139e681/sys-kernel/chromeos-kernel-3_10/chromeos-kernel-3_10-9999.ebuild

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/6ae3c9a5d382cfefc219e17c456053d058c39eb5

commit 6ae3c9a5d382cfefc219e17c456053d058c39eb5
Author: Douglas Anderson <dianders@chromium.org>
Date: Thu Oct 05 20:19:43 2017

cros-kernel2: Properly build host tools with the host compiler

Right now we're not giving HOSTCC to the kernel makefile so it
defaults to "gcc".  We should specify it.  Presumably this will be
useful to clang folks.

BUG= chromium:740719 ,  chromium:767565 
TEST=Compile a bunch of kernels

Change-Id: Ia69ae0f22be65d8e82ebdc5c06dfd93a5c595be3
Reviewed-on: https://chromium-review.googlesource.com/696186
Commit-Ready: Douglas Anderson <dianders@chromium.org>
Tested-by: Guenter Roeck <groeck@chromium.org>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>

[modify] https://crrev.com/6ae3c9a5d382cfefc219e17c456053d058c39eb5/sys-kernel/chromeos-kernel-3_8/chromeos-kernel-3_8-9999.ebuild
[modify] https://crrev.com/6ae3c9a5d382cfefc219e17c456053d058c39eb5/sys-kernel/chromeos-kernel-4_4/chromeos-kernel-4_4-9999.ebuild
[modify] https://crrev.com/6ae3c9a5d382cfefc219e17c456053d058c39eb5/sys-kernel/chromeos-kernel-3_18/chromeos-kernel-3_18-9999.ebuild
[modify] https://crrev.com/6ae3c9a5d382cfefc219e17c456053d058c39eb5/eclass/cros-kernel2.eclass
[modify] https://crrev.com/6ae3c9a5d382cfefc219e17c456053d058c39eb5/sys-kernel/chromeos-kernel-3_14/chromeos-kernel-3_14-9999.ebuild
[modify] https://crrev.com/6ae3c9a5d382cfefc219e17c456053d058c39eb5/sys-kernel/chromeos-kernel-4_12/chromeos-kernel-4_12-9999.ebuild
[modify] https://crrev.com/6ae3c9a5d382cfefc219e17c456053d058c39eb5/sys-kernel/chromeos-kernel-3_10/chromeos-kernel-3_10-9999.ebuild