From: Ihor Solodrai <ihor.solodrai@linux.dev>
To: James Clark <james.clark@linaro.org>,
Nathan Chancellor <nathan@kernel.org>,
Nick Desaulniers <nick.desaulniers+lkml@gmail.com>,
Bill Wendling <morbo@google.com>,
Justin Stitt <justinstitt@google.com>,
Jiri Kosina <jikos@kernel.org>,
Benjamin Tissoires <bentiss@kernel.org>,
Shuah Khan <shuah@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Namhyung Kim <namhyung@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>,
Adrian Hunter <adrian.hunter@intel.com>,
Andrii Nakryiko <andrii@kernel.org>,
Eduard Zingerman <eddyz87@gmail.com>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Martin KaFai Lau <martin.lau@linux.dev>,
Kumar Kartikeya Dwivedi <memxor@gmail.com>,
Song Liu <song@kernel.org>,
Yonghong Song <yonghong.song@linux.dev>
Cc: linux-kernel@vger.kernel.org, llvm@lists.linux.dev,
linux-input@vger.kernel.org, linux-kselftest@vger.kernel.org,
bpf@vger.kernel.org, linux-perf-users@vger.kernel.org
Subject: Re: [PATCH v2 5/6] tools/build: selftests: Allow versioning LLVM lld
Date: Fri, 10 Jul 2026 15:30:58 -0700 [thread overview]
Message-ID: <dc6cc14c-3ec8-48ee-8152-f24643679dfc@linux.dev> (raw)
In-Reply-To: <20260518-james-perf-llvm-version-v2-5-f12cc4f031d8@linaro.org>
On 5/18/26 2:03 AM, James Clark wrote:
> Building with LLVM=... could result in a different version of lld being
> used than the main toolchain for liburandom_read.so because it's
> hardcoded to "lld" in this makefile.
>
> Make it consistent with the rest of the LLVM toolchain by adding an LLD
> variable to Makefile.include. Keep the fallback for other architectures
> in tools/testing/selftests/bpf/Makefile as it seems like it's something
> specific to this make rule and shouldn't be global.
>
> Clang only accepts either a full path to "/x/x/ld.lld" or "lld-15" style
> inputs to "-fuse-ld=", so the only way to make it work with both
> prefixed and postfixed paths is to always take the full path. Also I
> don't think the original use of "lld" over "ld.lld" was significant as
> this is always a linux build, so that can be changed to make it work in
> both cases.
>
> Signed-off-by: James Clark <james.clark@linaro.org>
> ---
> tools/scripts/Makefile.include | 2 ++
> tools/testing/selftests/bpf/Makefile | 8 ++++----
> 2 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/tools/scripts/Makefile.include b/tools/scripts/Makefile.include
> index 380ad84ac51e..5c2d505cba62 100644
> --- a/tools/scripts/Makefile.include
> +++ b/tools/scripts/Makefile.include
> @@ -67,6 +67,7 @@ ifneq ($(LLVM),)
> $(call allow-override,HOSTAR,$(LLVM_PREFIX)llvm-ar$(LLVM_SUFFIX))
> $(call allow-override,LD,$(LLVM_PREFIX)ld.lld$(LLVM_SUFFIX))
> $(call allow-override,HOSTLD,$(LLVM_PREFIX)ld.lld$(LLVM_SUFFIX))
> + $(call allow-override,LLD,$(LLVM_PREFIX)ld.lld$(LLVM_SUFFIX))
> $(call allow-override,CXX,$(LLVM_PREFIX)clang++$(LLVM_SUFFIX))
> $(call allow-override,STRIP,$(LLVM_PREFIX)llvm-strip$(LLVM_SUFFIX))
> $(call allow-override,LLVM_STRIP,$(LLVM_PREFIX)llvm-strip$(LLVM_SUFFIX))
> @@ -91,6 +92,7 @@ else
> # Some tools still require Clang, LLC and/or LLVM utils
> $(call allow-override,CLANG,clang)
> $(call allow-override,LLC,llc)
> + $(call allow-override,LLD,ld.lld)
> $(call allow-override,LLVM_CONFIG,llvm-config)
> $(call allow-override,LLVM_OBJCOPY,llvm-objcopy)
> $(call allow-override,LLVM_STRIP,llvm-strip)
> diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile
> index 6ef6872adbc3..836e783f0170 100644
> --- a/tools/testing/selftests/bpf/Makefile
> +++ b/tools/testing/selftests/bpf/Makefile
> @@ -245,9 +245,9 @@ $(OUTPUT)/%:%.c
>
> # LLVM's ld.lld doesn't support all the architectures, so use it only on x86
> ifeq ($(SRCARCH),$(filter $(SRCARCH),x86 riscv))
> -LLD := lld
> +USE_LD := $(shell command -v $(LLD))
> else
> -LLD := $(shell command -v $(LD))
> +USE_LD := $(shell command -v $(LD))
Can confirm v2 fixes the v1 breakage I reported.
One nit on the empty USE_LD case the bot raised. It isn't actually a
build failure: if command -v finds nothing, USE_LD is empty and clang
gets a bare "-fuse-ld=".
Since it's unintentional, how about we just add a check to ensure the
linker was found?
Something like:
$(Q)test -n "$(USE_LD)" || { \
echo "$@: linker '$(LINKER)' not found - add it to PATH, or pass \
LLVM=/path/ or LLD=/abs/ld.lld" >&2; exit 1; }
> endif
>
> # Filter out -static for liburandom_read.so and its dependent targets so that static builds
> @@ -258,7 +258,7 @@ $(OUTPUT)/liburandom_read.so: urandom_read_lib1.c urandom_read_lib2.c liburandom
> $(filter-out -static,$(CFLAGS) $(LDFLAGS)) \
> $(filter %.c,$^) $(filter-out -static,$(LDLIBS)) \
> -Wno-unused-command-line-argument \
> - -fuse-ld=$(LLD) -Wl,-znoseparate-code -Wl,--build-id=sha1 \
> + -fuse-ld=$(USE_LD) -Wl,-znoseparate-code -Wl,--build-id=sha1 \
> -Wl,--version-script=liburandom_read.map \
> -fPIC -shared -o $@
>
> @@ -268,7 +268,7 @@ $(OUTPUT)/urandom_read: urandom_read.c urandom_read_aux.c $(OUTPUT)/liburandom_r
> $(filter-out -static,$(CFLAGS) $(LDFLAGS)) $(filter %.c,$^) \
> -Wno-unused-command-line-argument \
> -lurandom_read $(filter-out -static,$(LDLIBS)) -L$(OUTPUT) \
> - -fuse-ld=$(LLD) -Wl,-znoseparate-code -Wl,--build-id=sha1 \
> + -fuse-ld=$(USE_LD) -Wl,-znoseparate-code -Wl,--build-id=sha1 \
> -Wl,-rpath=. -o $@
>
> $(OUTPUT)/sign-file: ../../../../scripts/sign-file.c
>
next prev parent reply other threads:[~2026-07-10 22:31 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-18 9:03 [PATCH v2 0/6] tools/build: Allow versioning of all LLVM tools James Clark
2026-05-18 9:03 ` [PATCH v2 1/6] tools/build: Allow versioning of all LLVM tools defined in Makefile.include James Clark
2026-05-18 9:03 ` [PATCH v2 2/6] tools/build: Indent if else blocks James Clark
2026-05-18 9:03 ` [PATCH v2 3/6] selftests: Remove unused LLD variable James Clark
2026-05-21 15:30 ` Benjamin Tissoires
2026-05-18 9:03 ` [PATCH v2 4/6] tools/build: Allow versioning LLVM readelf James Clark
2026-05-18 16:05 ` Ian Rogers
2026-07-10 22:29 ` Ihor Solodrai
2026-07-14 16:41 ` James Clark
2026-07-14 18:49 ` Ihor Solodrai
2026-05-18 9:03 ` [PATCH v2 5/6] tools/build: selftests: Allow versioning LLVM lld James Clark
2026-05-18 9:32 ` sashiko-bot
2026-05-18 9:47 ` James Clark
2026-05-20 19:50 ` Arnaldo Carvalho de Melo
2026-05-21 13:16 ` James Clark
2026-07-10 22:26 ` Ihor Solodrai
2026-07-10 22:30 ` Ihor Solodrai [this message]
2026-05-18 9:03 ` [PATCH v2 6/6] tools/build: selftests: Remove some duplicate toolchain definitions James Clark
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=dc6cc14c-3ec8-48ee-8152-f24643679dfc@linux.dev \
--to=ihor.solodrai@linux.dev \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bentiss@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=irogers@google.com \
--cc=james.clark@linaro.org \
--cc=jikos@kernel.org \
--cc=jolsa@kernel.org \
--cc=justinstitt@google.com \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=mark.rutland@arm.com \
--cc=martin.lau@linux.dev \
--cc=memxor@gmail.com \
--cc=mingo@redhat.com \
--cc=morbo@google.com \
--cc=namhyung@kernel.org \
--cc=nathan@kernel.org \
--cc=nick.desaulniers+lkml@gmail.com \
--cc=peterz@infradead.org \
--cc=shuah@kernel.org \
--cc=song@kernel.org \
--cc=yonghong.song@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.