| Message ID | 20260505081625.849368-6-Deepesh.Varatharajan@windriver.com |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | Oe-selftest for Clang, LLVM, LLD | expand |
On Tue, 2026-05-05 at 01:16 -0700, Varatharajan, Deepesh via lists.openembedded.org wrote: > From: Deepesh Varatharajan <Deepesh.Varatharajan@windriver.com> > > 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 <Deepesh.Varatharajan@windriver.com> > --- > 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? Cheers, Richard
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 <Deepesh.Varatharajan@windriver.com> >> >> 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 <Deepesh.Varatharajan@windriver.com> >> --- >> 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. Regards, Deepesh > > Cheers, > > Richard
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 <Deepesh.Varatharajan@windriver.com> > > > > > > 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 <Deepesh.Varatharajan@windriver.com> > > > --- > > > 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. Cheers, Richard
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 <Deepesh.Varatharajan@windriver.com> >>>> >>>> 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 <Deepesh.Varatharajan@windriver.com> >>>> --- >>>> 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. > > Cheers, > > Richard 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 ? Regards, Deepesh > >
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 <Deepesh.Varatharajan@windriver.com> > > > > > > > > > > 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 <Deepesh.Varatharajan@windriver.com> > > > > > --- > > > > > 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
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 <Deepesh.Varatharajan@windriver.com> >>>>>> >>>>>> 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 <Deepesh.Varatharajan@windriver.com> >>>>>> --- >>>>>> 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
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