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. 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? Does the llvm test suite actually use the llvm-config target binary? Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#236484): https://lists.openembedded.org/g/openembedded-core/message/236484 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]] -=-=-=-=-=-=-=-=-=-=-=-
