Re: [PATCH 12/23] kbuild: avoid re-running compiler and linker probes

[Nathan Chancellor]

On Fri, Sep 11, 2026 at 07:24:50PM +0100, Lorenzo Stoakes (ARM) wrote:
> I mean this is a problem that already exists for any flags already specified in
> Kconfig.
> 
> Out-of-tree modules are historically something that we don't go to great lengths
> to support and haven't historically worried about breaking, either.
> 
> I'm sure distros can find ways around this if a problem were to arise. But I
> don't think it's something to worry about all that much.
> 
> I expect a _lot_ of these, in any case, would only require the compilers to be
> within a fair few major versions of one another anyway.

Yeah, while I know distributions will try to maintain a stable kernel
ABI to allow updating modules without updating the main kernel, I would
be very very surprised if they guaranteed compatability when building
external modules with a compiler different from the main kernel. If so,
I think they get to pick up the pieces :)

One issue that I found with my test matrix building with LLVM is that
cc-option in Kconfig does not guarantee use of either '-m32' / '-m64' or
'-mbig-endian' / '-mlittle-endian' to properly flip these options, which
could result in a flag being set (or not set) when it should be. For
example, building ARCH=powerpc pmac32_defconfig results in

  clang: error: argument unused during compilation: '-fno-stack-clash-protection' [-Werror,-Wunused-command-line-argument]
  make[4]: *** [scripts/Makefile.build:193: kernel/bounds.s] Error 1

because the 64-bit PowerPC little endian target supports this flag in
the PowerPC LLVM backend but the 32-bit big endian target does not.

I am not really sure what the best way to avoid this would be off the
top of my head... it might be safer to start with moving only the
warning flags to Kconfig since that is a truly frontend query.

-- 
Cheers,
Nathan