On 05-05-2026 17:02, Richard Purdie wrote:
CAUTION: This email comes from a non Wind River email account!
Do not click links or open attachments unless you recognize the sender and know
the content is safe.
On Tue, 2026-05-05 at 16:29 +0530, Deepesh Varatharajan wrote:
On 05-05-2026 15:36, Richard Purdie wrote:
CAUTION: This email comes from a non Wind River email account!
Do not click links or open attachments unless you recognize the sender and know
the content is safe.
On Tue, 2026-05-05 at 15:26 +0530, Varatharajan, Deepesh via
lists.openembedded.org wrote:
On 05-05-2026 15:06, Richard Purdie wrote:
CAUTION: This email comes from a non Wind River email account!
Do not click links or open attachments unless you recognize the sender and know
the content is safe.
On Tue, 2026-05-05 at 01:16 -0700, Varatharajan, Deepesh via
lists.openembedded.org wrote:
From: Deepesh Varatharajan <[email protected]>
Target LLVM tools are installed in the sysroot because they are needed
for llvm-lit to run tests. However, this leads Rust to pick up a target
llvm-config that cannot run on the host. Overwrite it with the native
llvm-config so Rust can execute it correctly.
Signed-off-by: Deepesh Varatharajan <[email protected]>
---
meta/recipes-devtools/rust/rust_1.94.1.bb | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-devtools/rust/rust_1.94.1.bb
b/meta/recipes-devtools/rust/rust_1.94.1.bb
index 3eb2a36406..e4a9f20e27 100644
--- a/meta/recipes-devtools/rust/rust_1.94.1.bb
+++ b/meta/recipes-devtools/rust/rust_1.94.1.bb
@@ -238,9 +238,10 @@ rust_runx () {
# Copy the natively built llvm-config into the target so we can run it.
Horrible,
# but works!
- if [ ${RUST_ALTERNATE_EXE_PATH_NATIVE} != ${RUST_ALTERNATE_EXE_PATH} -a !
-f ${RUST_ALTERNATE_EXE_PATH} ]; then
+ if [ ${RUST_ALTERNATE_EXE_PATH_NATIVE} != ${RUST_ALTERNATE_EXE_PATH} ];
then
mkdir -p `dirname ${RUST_ALTERNATE_EXE_PATH}`
- cp ${RUST_ALTERNATE_EXE_PATH_NATIVE} ${RUST_ALTERNATE_EXE_PATH}
+ rm -f ${RUST_ALTERNATE_EXE_PATH}
+ cp -f ${RUST_ALTERNATE_EXE_PATH_NATIVE} ${RUST_ALTERNATE_EXE_PATH}
patchelf --remove-rpath ${RUST_ALTERNATE_EXE_PATH}
fi
This appears to be a consequence of the new install in "clang: Enable
cmake flags for llvm, clang, lld tests". Perhaps we should just not
install llvm-config there if it is going to cause problems and need to
be overwritten?
Yes, this is due to the new installations. We now need the target
llvm-config to run the Clang
family test suite inside QEMU for the target. Previously, we didn’t
install LLVM target tools,
but running the Clang test suite for the target requires these tools to
be present in bin so
that llvm-lit can use them.
Also, the existing check is somewhat odd. Even if llvm-config exists in
${RUST_ALTERNATE_EXE_PATH},
it can’t be used for building Rust because that version is built for the
target. Therefore,
overriding it with the native llvm-config makes sense.
We simply can't mix target and native binaries like this.
Think about what happens if you take target sstate built on x86-64 and
reuse it on an aarch64 host system.
Yes, I see your point about mixing native and target binaries and the
potential impact on sstate reuse.
However, this behavior already existed before this change. We were
copying the native llvm-config into
the target sysroot when the paths differed. The only difference here is
that we now always overwrite it
instead of skipping when a file already exists.
With the recent Clang changes, a target llvm-config is now installed,
which causes the previous conditional
check to skip the copy. That leads to Rust picking up a target-built
llvm-config, which is not usable for
building Rust.
So this change doesn’t introduce new mixing. It ensures we consistently
use the native llvm-config, which
is what the original logic intended. Did I misunderstood something ?
Looking at the code, it is in rust_runx and that code us used during
compile/install so it only affects things locally, it doesn't change
the sstate objects. I was thinking this was changing installed files,
sorry.
The check for files existing is probably there due to the fact the
function can be called multiple times and we want to copy the first
time only.
True
I still have to wonder why we are installing something which we then
have to overwrite though. If we have to overwrite it, we shouldn't be
installing it in the first place?
The target llvm-config is required for running the Clang test suite,
since those tests depend on LLVM and are
executed under QEMU, where a target binary is needed.
As part of that, we install the target llvm-config into the sysroot.
However, Rust also depends on LLVM, and
during its build it picks up llvm-config from that same location. In
this case, using the target llvm-config
doesn’t work, because Rust needs a native binary for the host build.
So the situation is a bit split:
For Clang tests, we need the target llvm-config available in the sysroot
so it can run under QEMU.
For building Rust, we need the native llvm-config, not the target one.
The overwrite ensures that Rust consistently uses the native
llvm-config, while still allowing the
target one to be installed for Clang test purposes. This doesn’t change
the intended behavior, but
resolves the conflict between the two use cases.
Does the llvm test suite actually use the llvm-config target binary?
Yes it does.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#236486):
https://lists.openembedded.org/g/openembedded-core/message/236486
Mute This Topic: https://lists.openembedded.org/mt/119157533/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
