In ChromeOS and Gentoo we catch any unwanted mixed Clang/LLVM
and GCC/binutils usage via toolchain wrappers which fail builds.
This has revealed that GCC is called unconditionally in Clang
configured builds to populate GCC_TOOLCHAIN_DIR.

Allow the user to override CLANG_CROSS_FLAGS to avoid the GCC
call - in our case we set the var directly in the ebuild recipe.

In theory Clang could be able to autodetect these settings so
this logic could be removed entirely, but in practice as the
commit cebdb7374577 ("tools: Help cross-building with clang")
mentions, this does not always work, so giving distributions
more control to specify their flags & sysroot is beneficial.

Suggested-by: Manoj Gupta <manojgupta@chromium.com>
Suggested-by: Nathan Chancellor <nathan@kernel.org>
Acked-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Adrian Ratiu <adrian.ratiu@collabora.com>
---
Changes in v2:
  * Replaced variable override GCC_TOOLCHAIN_DIR -> CLANG_CROSS_FLAGS
---
 tools/scripts/Makefile.include | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/tools/scripts/Makefile.include b/tools/scripts/Makefile.include
index 79d102304470..b9b1deacc4eb 100644
--- a/tools/scripts/Makefile.include
+++ b/tools/scripts/Makefile.include
@@ -89,6 +89,9 @@ ifeq ($(CC_NO_CLANG), 1)
 EXTRA_WARNINGS += -Wstrict-aliasing=3
 
 else ifneq ($(CROSS_COMPILE),)
+# allow userspace to override CLANG_CROSS_FLAGS to specify their own
+# sysroots and flags or to avoid the GCC call in pure Clang builds
+ifeq ($(CLANG_CROSS_FLAGS),)
 CLANG_CROSS_FLAGS := --target=$(notdir $(CROSS_COMPILE:%-=%))
 GCC_TOOLCHAIN_DIR := $(dir $(shell which $(CROSS_COMPILE)gcc 2>/dev/null))
 ifneq ($(GCC_TOOLCHAIN_DIR),)
@@ -96,6 +99,7 @@ CLANG_CROSS_FLAGS += --prefix=$(GCC_TOOLCHAIN_DIR)$(notdir $(CROSS_COMPILE))
 CLANG_CROSS_FLAGS += --sysroot=$(shell $(CROSS_COMPILE)gcc -print-sysroot)
 CLANG_CROSS_FLAGS += --gcc-toolchain=$(realpath $(GCC_TOOLCHAIN_DIR)/..)
 endif # GCC_TOOLCHAIN_DIR
+endif # CLANG_CROSS_FLAGS
 CFLAGS += $(CLANG_CROSS_FLAGS)
 AFLAGS += $(CLANG_CROSS_FLAGS)
 endif # CROSS_COMPILE
-- 
2.35.1

On 3/8/22 1:14 PM, Adrian Ratiu wrote:
> In ChromeOS and Gentoo we catch any unwanted mixed Clang/LLVM
> and GCC/binutils usage via toolchain wrappers which fail builds.
> This has revealed that GCC is called unconditionally in Clang
> configured builds to populate GCC_TOOLCHAIN_DIR.
> 
> Allow the user to override CLANG_CROSS_FLAGS to avoid the GCC
> call - in our case we set the var directly in the ebuild recipe.
> 
> In theory Clang could be able to autodetect these settings so
> this logic could be removed entirely, but in practice as the
> commit cebdb7374577 ("tools: Help cross-building with clang")
> mentions, this does not always work, so giving distributions
> more control to specify their flags & sysroot is beneficial.
> 
> Suggested-by: Manoj Gupta <manojgupta@chromium.com>
> Suggested-by: Nathan Chancellor <nathan@kernel.org>
> Acked-by: Nathan Chancellor <nathan@kernel.org>
> Signed-off-by: Adrian Ratiu <adrian.ratiu@collabora.com>
> ---
> Changes in v2:
>    * Replaced variable override GCC_TOOLCHAIN_DIR -> CLANG_CROSS_FLAGS

As I understand it from [0] and given we're late in the cycle, this is
targeted for bpf-next not bpf, right?

Thanks,
Daniel

   [0] https://lore.kernel.org/lkml/87czjk4osi.fsf@ryzen9.i-did-not-set--mail-host-address--so-tickle-me/

Hello Daniel,

On Tue, 08 Mar 2022, Daniel Borkmann <daniel@iogearbox.net> wrote:
> On 3/8/22 1:14 PM, Adrian Ratiu wrote: 
>> In ChromeOS and Gentoo we catch any unwanted mixed Clang/LLVM 
>> and GCC/binutils usage via toolchain wrappers which fail 
>> builds.  This has revealed that GCC is called unconditionally 
>> in Clang configured builds to populate GCC_TOOLCHAIN_DIR. 
>> Allow the user to override CLANG_CROSS_FLAGS to avoid the GCC 
>> call - in our case we set the var directly in the ebuild 
>> recipe.   In theory Clang could be able to autodetect these 
>> settings so this logic could be removed entirely, but in 
>> practice as the commit cebdb7374577 ("tools: Help 
>> cross-building with clang") mentions, this does not always 
>> work, so giving distributions more control to specify their 
>> flags & sysroot is beneficial.   Suggested-by: Manoj Gupta 
>> <manojgupta@chromium.com> Suggested-by: Nathan Chancellor 
>> <nathan@kernel.org> Acked-by: Nathan Chancellor 
>> <nathan@kernel.org> Signed-off-by: Adrian Ratiu 
>> <adrian.ratiu@collabora.com> --- Changes in v2: 
>>    * Replaced variable override GCC_TOOLCHAIN_DIR -> 
>>    CLANG_CROSS_FLAGS 
> 
> As I understand it from [0] and given we're late in the cycle, 
> this is targeted for bpf-next not bpf, right? 
>

Yes, let's target this for bpf-next. The issue was introduced in 
the 5.17 cycle but indeed it's late. I can do a stable backport to 
5.17 after it releases.

Thanks,
Adrian

> Thanks,
> Daniel
>
>    [0] https://lore.kernel.org/lkml/87czjk4osi.fsf@ryzen9.i-did-not-set--mail-host-address--so-tickle-me/

On 3/8/22 11:14 PM, Adrian Ratiu wrote:
> On Tue, 08 Mar 2022, Daniel Borkmann <daniel@iogearbox.net> wrote:
>> On 3/8/22 1:14 PM, Adrian Ratiu wrote:
>>> In ChromeOS and Gentoo we catch any unwanted mixed Clang/LLVM and GCC/binutils usage via toolchain wrappers which fail builds.  This has revealed that GCC is called unconditionally in Clang configured builds to populate GCC_TOOLCHAIN_DIR. Allow the user to override CLANG_CROSS_FLAGS to avoid the GCC call - in our case we set the var directly in the ebuild recipe.   In theory Clang could be able to autodetect these settings so this logic could be removed entirely, but in practice as the commit cebdb7374577 ("tools: Help cross-building with clang") mentions, this does not always work, so giving distributions more control to specify their flags & sysroot is beneficial.   Suggested-by: Manoj Gupta <manojgupta@chromium.com> Suggested-by: Nathan Chancellor <nathan@kernel.org> Acked-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Adrian Ratiu <adrian.ratiu@collabora.com> --- Changes in v2:    * Replaced variable override GCC_TOOLCHAIN_DIR ->    CLANG_CROSS_FLAGS 
>>
>> As I understand it from [0] and given we're late in the cycle, this is targeted for bpf-next not bpf, right?
> 
> Yes, let's target this for bpf-next. The issue was introduced in the 5.17 cycle but indeed it's late. I can do a stable backport to 5.17 after it releases.

Ok, sgtm. Given it has an Ack by Nathan, I've pushed it to bpf-next.

Thanks everyone,
Daniel