From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: James Clark <james.clark@linaro.org>
Cc: sashiko-reviews@lists.linux.dev, dmitry.torokhov@gmail.com,
linux-perf-users@vger.kernel.org, bpf@vger.kernel.org,
linux-input@vger.kernel.org
Subject: Re: [PATCH v2 5/6] tools/build: selftests: Allow versioning LLVM lld
Date: Wed, 20 May 2026 16:50:40 -0300 [thread overview]
Message-ID: <ag4QkPOCQ5LWy-U3@x1> (raw)
In-Reply-To: <ef5688a7-3e1d-47be-aca7-cc6e564e059c@linaro.org>
On Mon, May 18, 2026 at 10:47:53AM +0100, James Clark wrote:
>
>
> On 18/05/2026 10:32 am, sashiko-bot@kernel.org wrote:
> > Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> > - [Medium] Empty USE_LD variable causes clang build failure in selftests when ld.lld is not in PATH.
> > --
> >
> > commit 371ca22c55bb0fa6502ac06f7b33d63418ad16ff
> > Author: James Clark <james.clark@linaro.org>
> >
> > tools/build: selftests: Allow versioning LLVM lld
> >
> > This commit adds an LLD variable to Makefile.include to allow versioning of
> > LLVM's linker, keeping it consistent with the rest of the LLVM toolchain. It
> > modifies the BPF selftests Makefile to resolve the full path of the linker
> > using the command -v shell utility.
> >
> > > diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile
> > > index 6ef6872adbc3e..836e783f0170e 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))
> >
> > Does this cause the build to fail if the toolchain directory is not in the
> > system PATH?
> >
> > If a user explicitly specifies the compiler using an absolute path like
> > CLANG=/path/to/clang, but does not add the toolchain directory to their PATH,
> > the command -v utility will return an empty string.
>
> If they don't use LLVM= and use CLANG= with an absolute path then they need
> to set all the tools with an absolute path. That's the problem that setting
> the path with a prefix for all tools with LLVM= solved.
>
> I suppose this could _technically_ be a regression, but so could adding any
> new build rule that added a new tool that wouldn't be set in someones
> existing build command. Being that strict would mean we can't ever add new
> tools so I don't think this is an issue. And I don't think there's a way to
> solve this and also respect the documented rules of LLVM=
Hey, this touches several tools and libs, did you get acks besides the
one from Ian?
- Arnaldo
next prev parent reply other threads:[~2026-05-20 19:50 UTC|newest]
Thread overview: 13+ 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-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 [this message]
2026-05-21 13:16 ` James Clark
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=ag4QkPOCQ5LWy-U3@x1 \
--to=acme@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=dmitry.torokhov@gmail.com \
--cc=james.clark@linaro.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=sashiko-reviews@lists.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.