| Message ID | 20260302132815.2922014-1-sunilkumar.dora@windriver.com |
|---|---|
| State | Under Review |
| Headers | show |
| Series | rust: Enable dynamic LLVM linking for nativesdk-rust | expand |
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
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
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
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
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))