[PATCH] rust: Enable dynamic LLVM linking for nativesdk-rust

[PATCH] rust: Enable dynamic LLVM linking for nativesdk-rust

[sunilkumar.dora]

From: Sunil Dora <sunilkumar.dora@windriver.com>

Fixes [Yocto #16058]

The issue is still observed with nativesdk-rust when sstate artifacts
built with different host toolchain versions are reused.

Although dynamic LLVM linking was already enabled for rust-native,
nativesdk-rust can also reuse sstate artifacts across host toolchain
generations. In such cases, static linking of LLVM objects may result
in mixing objects built with different toolchains, leading to runtime
segmentation faults.

Extend the fix to nativesdk-rust by enabling dynamic LLVM linking
(link-shared = true) to avoid these crashes.

Signed-off-by: Sunil Dora <sunilkumar.dora@windriver.com>
---
 meta/recipes-devtools/rust/rust_1.93.0.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/rust/rust_1.93.0.bb b/meta/recipes-devtools/rust/rust_1.93.0.bb
index 2be0bd8d89..06dc8a376c 100644
--- a/meta/recipes-devtools/rust/rust_1.93.0.bb
+++ b/meta/recipes-devtools/rust/rust_1.93.0.bb
@@ -124,7 +124,7 @@ python do_configure() {
 
     # [llvm]
     config.add_section("llvm")
-    if d.getVar('PN') == "rust-native":
+    if d.getVar('PN') in ("rust-native", "nativesdk-rust"):
         config.set("llvm", "link-shared", e(True))
     config.set("llvm", "static-libstdcpp", e(False))
     config.set("llvm", "download-ci-llvm", e(False))
-- 
2.49.0

Re: [OE-core] [PATCH] rust: Enable dynamic LLVM linking for nativesdk-rust

[Alexander Kanavin]

On Mon, 2 Mar 2026 at 14:28, Dora, Sunil Kumar via
lists.openembedded.org
<SunilKumar.Dora=windriver.com@lists.openembedded.org> wrote:
> -    if d.getVar('PN') == "rust-native":
> +    if d.getVar('PN') in ("rust-native", "nativesdk-rust"):

Looking at the error, it seems the problematic binary in nativesdk
builds is rustc-1.93.0-src/build/bootstrap/debug/rustc - does this
mean building target rust has the same issue? Should we just go back
to the initial patch, which sets link-shared for all rust variants
without conditions?

Alex

Re: [OE-core] [PATCH] rust: Enable dynamic LLVM linking for nativesdk-rust

[Dora, Sunil Kumar]

[-- Attachment #1: Type: text/plain, Size: 2188 bytes --]

Hi Alex,

Earlier in the discussion, the idea was to limit the workaround to the native side if possible, so that target Rust builds remain unchanged.
See: https://lists.openembedded.org/g/openembedded-core/message/231258

Based on that, the patch initially enabled dynamic LLVM linking only for rust-native. Later, we realized that nativesdk-rust also needs this workaround.

Regarding the bootstrap binary you mentioned (rustc-1.93.0-src/build/bootstrap/debug/rustc), I tried to reproduce the issue locally by following the steps discussed earlier in YPBZ-16058.
With the current change, where rust-native and nativesdk-rust link LLVM dynamically, I was not able to reproduce a crash in the target rustc.

It is possible that I may be missing something in the setup. Could you please suggest if there are any additional steps to confirm whether target Rust builds could also be affected?

Moreover, we have not seen any target rustc crashes in AB so far (with rust-native currently linking LLVM dynamically in oe-core master).


Thanks,
Sunil
________________________________
From: Alexander Kanavin <alex.kanavin@gmail.com>
Sent: Thursday, March 5, 2026 5:02 PM
To: Dora, Sunil Kumar <SunilKumar.Dora@windriver.com>
Cc: openembedded-core@lists.openembedded.org <openembedded-core@lists.openembedded.org>; Kokkonda, Sundeep <Sundeep.Kokkonda@windriver.com>
Subject: Re: [OE-core] [PATCH] rust: Enable dynamic LLVM linking for nativesdk-rust

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 Mon, 2 Mar 2026 at 14:28, Dora, Sunil Kumar via
lists.openembedded.org
<SunilKumar.Dora=windriver.com@lists.openembedded.org> wrote:
> -    if d.getVar('PN') == "rust-native":
> +    if d.getVar('PN') in ("rust-native", "nativesdk-rust"):

Looking at the error, it seems the problematic binary in nativesdk
builds is rustc-1.93.0-src/build/bootstrap/debug/rustc - does this
mean building target rust has the same issue? Should we just go back
to the initial patch, which sets link-shared for all rust variants
without conditions?

Alex

[-- Attachment #2: Type: text/html, Size: 6050 bytes --]

Re: [OE-core] [PATCH] rust: Enable dynamic LLVM linking for nativesdk-rust

[Alexander Kanavin]

On Wed, 11 Mar 2026 at 14:46, Dora, Sunil Kumar
<SunilKumar.Dora@windriver.com> wrote:
> Regarding the bootstrap binary you mentioned (rustc-1.93.0-src/build/bootstrap/debug/rustc), I tried to reproduce the issue locally by following the steps discussed earlier in YPBZ-16058.
> With the current change, where rust-native and nativesdk-rust link LLVM dynamically, I was not able to reproduce a crash in the target rustc.
>
> It is possible that I may be missing something in the setup. Could you please suggest if there are any additional steps to confirm whether target Rust builds could also be affected?
>
> Moreover, we have not seen any target rustc crashes in AB so far (with rust-native currently linking LLVM dynamically in oe-core master).

Hello Sunil,

as you know, rustc crashes require a very particular build sequence
involving cross-distro llvm sstate sharing. Autobuilder probably
hasn't hit that combination of distros yet.

Here's how I confirmed target rust is also affected.

First, the logs:
https://autobuilder.yoctoproject.org/valkyrie/api/v2/logs/5451595/raw_inline
https://autobuilder.yoctoproject.org/valkyrie/api/v2/logs/5464376/raw_inline

I wasn't quite correct: the crash is not in bootstrap rustc, but in
stage1 compiler, particularly
/srv/pokybuild/yocto-worker/qemuarm-oecore/build/build/tmp/work/x86_64-nativesdk-oesdk-linux/nativesdk-rust/1.93.0/sources/rustc-1.93.0-src/build/x86_64-unknown-linux-gnu/stage1/lib/librustc_driver-589f8dcb4946d37d.so

Then, I ran this locally against current master (e.g. only native rust
is using shared llvm linking):
$ bitbake -c install rust-native rust nativesdk-rust

Then I went and inspected
build/x86_64-unknown-linux-gnu/stage1/lib/librustc_driver-589f8dcb4946d37d.so
in all three build directories.

rust-native is linking stage1 pieces with libLLVM.so dynamically:

$ ldd /srv/storage/alex/yocto/build-64-alt/tmp/work/x86_64-linux/rust-native/1.94.0/sources/rustc-1.94.0-src/build/x86_64-unknown-linux-gnu/stage1/bin/../lib/librustc_driver-f5e56a2b9cd1fb54.so
    linux-vdso.so.1 (0x00007f1ee2f7a000)
    libLLVM.so.21.1 =>
/srv/storage/alex/yocto/build-64-alt/tmp/work/x86_64-linux/rust-native/1.94.0/recipe-sysroot-native/usr/lib/libLLVM.so.21.1
(0x00007f1ed6e00000)
    libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f1ed6a00000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f1ee2f3a000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1ed680b000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f1ee2f7c000)
    libffi.so.8 =>
/srv/storage/alex/yocto/build-64-alt/tmp/work/x86_64-linux/rust-native/1.94.0/recipe-sysroot-native/usr/lib/./libffi.so.8
(0x00007f1ee2f28000)
    libz.so.1 =>
/srv/storage/alex/yocto/build-64-alt/tmp/work/x86_64-linux/rust-native/1.94.0/recipe-sysroot-native/usr/lib/./libz.so.1
(0x00007f1ee2f0e000)
    libzstd.so.1 =>
/srv/storage/alex/yocto/build-64-alt/tmp/work/x86_64-linux/rust-native/1.94.0/recipe-sysroot-native/usr/lib/./libzstd.so.1
(0x00007f1ee2e41000)
    libxml2.so.16 =>
/srv/storage/alex/yocto/build-64-alt/tmp/work/x86_64-linux/rust-native/1.94.0/recipe-sysroot-native/usr/lib/./libxml2.so.16
(0x00007f1edd2c3000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f1ed6d10000)

nativesdk-rust and target rust do not, which means they both
statically link with llvm:

alex@Zen2:/srv/storage/alex/yocto/build-64-alt$ ldd
/srv/storage/alex/yocto/build-64-alt/tmp/work/aarch64-nativesdk-pokysdk-linux/nativesdk-rust/1.94.0/sources/rustc-1.94.0-src/build/x86_64-unknown-linux-gnu/stage1/bin/../lib/librustc_driver-cb9e6f92243d3a7f.so
    linux-vdso.so.1 (0x00007f5b44adc000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f5b39d10000)
    libz.so.1 =>
/srv/storage/alex/yocto/build-64-alt/tmp/work/aarch64-nativesdk-pokysdk-linux/nativesdk-rust/1.94.0/recipe-sysroot-native/usr/lib/libz.so.1
(0x00007f5b39cf6000)
    libzstd.so.1 =>
/srv/storage/alex/yocto/build-64-alt/tmp/work/aarch64-nativesdk-pokysdk-linux/nativesdk-rust/1.94.0/recipe-sysroot-native/usr/lib/libzstd.so.1
(0x00007f5b39c29000)
    libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f5b39800000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f5b39bfc000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f5b3960b000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f5b44ade000)

(running ldd for target rust shows the same output)

This almost certainly means that the proposed nativesdk-specific fix
is incomplete. It needs to apply to all possibilities, nativesdk,
native and target.

Alex

Re: [PATCH] rust: Enable dynamic LLVM linking for nativesdk-rust

[Dora, Sunil Kumar]

[-- Attachment #1: Type: text/plain, Size: 231 bytes --]

Sure Alex. Thanks for the clarification, that makes sense.
I'll update the change to enable shared LLVM linking for all Rust variants to ensure the stage1 compiler
is consistently built with dynamic LLVM.

Thanks,
Sunil Dora

[-- Attachment #2: Type: text/html, Size: 264 bytes --]

Re: [OE-core] [PATCH] rust: Enable dynamic LLVM linking for nativesdk-rust

[Alexander Kanavin]

On Thu, 5 Mar 2026 at 12:32, Alexander Kanavin via
lists.openembedded.org <alex.kanavin=gmail.com@lists.openembedded.org>
wrote:
> > -    if d.getVar('PN') == "rust-native":
> > +    if d.getVar('PN') in ("rust-native", "nativesdk-rust"):
>
> Looking at the error, it seems the problematic binary in nativesdk
> builds is rustc-1.93.0-src/build/bootstrap/debug/rustc - does this
> mean building target rust has the same issue? Should we just go back
> to the initial patch, which sets link-shared for all rust variants
> without conditions?

I just sent a patch that does this.

Alex