On Thu, Jul 24, 2025 at 10:32:45AM +0200, Thomas Weißschuh wrote:
The userprogs infrastructure does not expect clang being used with GNU ld and in that case uses /usr/bin/ld for linking, not the configured $(LD). This fallback is problematic as it will break when cross-compiling. Mixing clang and GNU ld is used for example when building for SPARC64, as ld.lld is not sufficient; see Documentation/kbuild/llvm.rst.
Relax the check around --ld-path so it gets used for all linkers.
Fixes: dfc1b168a8c4 ("kbuild: userprogs: use correct lld when linking through clang") Cc: stable@vger.kernel.org Signed-off-by: Thomas Weißschuh thomas.weissschuh@linutronix.de
Nathan, you originally proposed the check for $(CONFIG_LD_IS_LLD) [0], could you take a look at this?
I would expect this to be okay but I have not explicitly tested it. I had not considered the case of GNU ld being used since aside from sparc64, there is not another architecture that supports clang but not ld.lld.
Reviewed-by: Nathan Chancellor nathan@kernel.org
Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile index c09766beb7eff4780574682b8ea44475fc0a5188..e300c6546c845c300edb5f0033719963c7da8f9b 100644 --- a/Makefile +++ b/Makefile @@ -1134,7 +1134,7 @@ KBUILD_USERCFLAGS += $(filter -m32 -m64 --target=%, $(KBUILD_CPPFLAGS) $(KBUILD KBUILD_USERLDFLAGS += $(filter -m32 -m64 --target=%, $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS))
Does KBUILD_USERCFLAGS respect LLVM_IAS? sparc64 does not use the integrated assembler yet (as far as I am aware) so I think we probably need to filter '--prefix=' and '-fno-integrated-as' to avoid further issues with assembling?
# userspace programs are linked via the compiler, use the correct linker -ifeq ($(CONFIG_CC_IS_CLANG)$(CONFIG_LD_IS_LLD),yy) +ifneq ($(CONFIG_CC_IS_CLANG),)
At this point, I think this can just become
ifdef CONFIG_CC_IS_CLANG
KBUILD_USERLDFLAGS += --ld-path=$(LD) endif
base-commit: 6832a9317eee280117cd695fa885b2b7a7a38daf change-id: 20250723-userprogs-clang-gnu-ld-7a1c16fc852d
Best regards,
Thomas Weißschuh thomas.weissschuh@linutronix.de