[PATCH RFC 0/3] RFC: Fixing rust segfault (#16058) to support Ubuntu 26.04 on Scarthgap

[PATCH RFC 0/3] RFC: Fixing rust segfault (#16058) to support Ubuntu 26.04 on Scarthgap

[Yoann Congal]

Hello,

I'm currently trying to support Ubuntu 26.04 on Scarthgap, but by doing
so, I awaken bugs fixed on master. The current (and hardest one yet) is:
  16058 – AB-INT: rust do_test_compile/do_install segfault
  https://bugzilla.yoctoproject.org/show_bug.cgi?id=16058

I've this bug triggered here: 
https://autobuilder.yoctoproject.org/valkyrie/?#/builders/40/builds/3981

To fix that, I've tried to backport the fixes mentionned in the bug:
* commit 74ba238ff1ba ("rust: Enable dynamic linking with llvm")
* (commit c31859be39c6 ("rust-llvm: Disable libedit") because I
  trigerred a libedit related linking issue)
* commit d0671c3dad87 ("rust: enable dynamic LLVM linking by default")

But that last commit appears difficult to backport: It was made after
master switch the LLVM compiling rust from rust-llvm to common llvm.

I've hacked the backport until it passes testing:
https://autobuilder.yoctoproject.org/valkyrie/?#/builders/29/builds/4085
... but I'm really *NOT* sure this is the right approach. Hence this RFC
with the patches I ended-up with.

If anyone could check/review/improve these patches to help me get them
to a mergable state, that'd be nice. Otherwise, I would have no other
choice than never support Ubuntu 26.04 on Scarthgap.

Thanks!

I've copied the bug CC list for awareness:

Signed-off-by: Yoann Congal <yoann.congal@smile.fr>
---
Richard Purdie (1):
      rust-llvm: Disable libedit

Sunil Dora (2):
      rust: Enable dynamic linking with llvm
      WIP backport: rust: enable dynamic LLVM linking by default

 meta/lib/oeqa/selftest/cases/rust.py           |  2 +-
 meta/recipes-devtools/rust/rust-llvm_1.75.0.bb | 40 ++++++++++++++++++++++++--
 meta/recipes-devtools/rust/rust_1.75.0.bb      |  6 ++++
 3 files changed, 45 insertions(+), 3 deletions(-)
---
base-commit: f42bc5a91196691a30d92482fdf2eca7eabdbe25
change-id: 20260626-ycongal-scarthgap-rust-segfault-812ae2a9c95d

Best regards,
-- 
Yoann Congal <yoann.congal@smile.fr>

[PATCH RFC 1/3] rust: Enable dynamic linking with llvm

[Yoann Congal]

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

Fixes [Yocto #16058]

A segmentation fault occurs in rustc (e.g. in
llvm::X86ReadAdvanceTable) when reusing sstate artifacts built with
different host toolchain versions.

Issue sequence:
1. llvm-native is built with a newer toolchain
   (e.g. GCC 15/Binutils 2.45).
2. rust-native is later built with an older linker.
   (e.g. GCC 12/Binutils 2.40).
3. The older linker statically links parts of llvm-native into
   librustc_driver.
4. The resulting binary crashes at runtime inside the statically
   linked LLVM code.

The corruption happens at link time when mixing static native objects
produced by different toolchain generations.

Enable dynamic LLVM linking (link-shared = true) for rust-native so rustc
links against libLLVM.so instead of static archives, avoiding host linker
incompatibilities when reusing sstate artifacts.

Signed-off-by: Sunil Dora <sunilkumar.dora@windriver.com>
Suggested-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 74ba238ff1ba1e9b612aece1989b828f3a8f8770)
Signed-off-by: Yoann Congal <yoann.congal@smile.fr>
---
 meta/recipes-devtools/rust/rust_1.75.0.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-devtools/rust/rust_1.75.0.bb b/meta/recipes-devtools/rust/rust_1.75.0.bb
index b9348bf05071016cf27880258e27babb3f2eec90..f037bb33715dc4ba7cbb489ab1599ac6c8c875a4 100644
--- a/meta/recipes-devtools/rust/rust_1.75.0.bb
+++ b/meta/recipes-devtools/rust/rust_1.75.0.bb
@@ -128,6 +128,8 @@ python do_configure() {
 
     # [llvm]
     config.add_section("llvm")
+    if d.getVar('PN') == "rust-native":
+        config.set("llvm", "link-shared", e(True))
     config.set("llvm", "static-libstdcpp", e(False))
     if "llvm" in (d.getVar('TC_CXX_RUNTIME') or ""):
         config.set("llvm", "use-libcxx", e(True))

-- 
2.47.3

[PATCH RFC 2/3] rust-llvm: Disable libedit

[Yoann Congal]

From: Richard Purdie <richard.purdie@linuxfoundation.org>

This option currently floats and is leading to non-deterministic builds. It
is used for commandline option tab completion which we don't need in our
builds in general, let alone internally within rust's llvm.

This should fix autobuilder deterministic build issues.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit c31859be39c68f215576ba73b8a3d66c8ea590d3)
Signed-off-by: Yoann Congal <yoann.congal@smile.fr>
---
 meta/recipes-devtools/rust/rust-llvm_1.75.0.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-devtools/rust/rust-llvm_1.75.0.bb b/meta/recipes-devtools/rust/rust-llvm_1.75.0.bb
index cba41c739e9692ec7b2cd7ee07554ab00dc98fc5..4adaf5fbf6d31b1984a81e864285c1e06218e325 100644
--- a/meta/recipes-devtools/rust/rust-llvm_1.75.0.bb
+++ b/meta/recipes-devtools/rust/rust-llvm_1.75.0.bb
@@ -46,6 +46,7 @@ EXTRA_OECMAKE = " \
     -DLLVM_ENABLE_ZSTD=OFF \
     -DLLVM_ENABLE_LIBXML2=OFF \
     -DLLVM_ENABLE_FFI=OFF \
+    -DLLVM_ENABLE_LIBEDIT=OFF \
     -DLLVM_INSTALL_UTILS=ON \
     -DLLVM_BUILD_EXAMPLES=OFF \
     -DLLVM_INCLUDE_EXAMPLES=OFF \

-- 
2.47.3

[PATCH RFC 3/3] WIP backport: rust: enable dynamic LLVM linking by default

[Yoann Congal]

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

Fixes [YOCTO #16058]

Enable dynamic linking with LLVM (link-shared) for all rust variants
(native, nativesdk and target) via a PACKAGECONFIG option, enabled
by default. This prevents segmentation faults when reusing sstate
artifacts built with different host toolchains.

Update multilib library symlinking to include shared libraries and
adjust the rust selftest to install llvm so the dynamically linked
compiler can run correctly.

Suggested-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Sunil Dora <sunilkumar.dora@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit d0671c3dad87a063b3a41dd07cde89b5684e692c)
[YC: WIP Backport:
* moveid from llvm to rust-llvm (llvm unification has not happened on
  scarthgap
* made changes limited to -native/nativesdk- to avoid changing target
  output without reason
* Redid FILES* packaging around $PN/$PN-dev split to handle LLVM.so files]
Signed-off-by: Yoann Congal <yoann.congal@smile.fr>
---
 meta/lib/oeqa/selftest/cases/rust.py           |  2 +-
 meta/recipes-devtools/rust/rust-llvm_1.75.0.bb | 39 ++++++++++++++++++++++++--
 meta/recipes-devtools/rust/rust_1.75.0.bb      |  8 ++++--
 3 files changed, 44 insertions(+), 5 deletions(-)

diff --git a/meta/lib/oeqa/selftest/cases/rust.py b/meta/lib/oeqa/selftest/cases/rust.py
index 26f132edc4d55f260f835a996181834588249d13..b6912f646e37d0edb07bb178d2d3671ac1a67542 100644
--- a/meta/lib/oeqa/selftest/cases/rust.py
+++ b/meta/lib/oeqa/selftest/cases/rust.py
@@ -51,7 +51,7 @@ class RustSelfTestSystemEmulated(OESelftestTestCase, OEPTestResultTestCase):
         bitbake("{} -c test_compile".format(recipe))
         builddir = get_bb_var("RUSTSRC", "rust")
         # build core-image-minimal with required packages
-        default_installed_packages = ["libgcc", "libstdc++", "libatomic", "libgomp"]
+        default_installed_packages = ["libgcc", "libstdc++", "libatomic", "libgomp", "llvm"]
         features = []
         features.append('IMAGE_FEATURES += "ssh-server-dropbear"')
         features.append('CORE_IMAGE_EXTRA_INSTALL += "{0}"'.format(" ".join(default_installed_packages)))
diff --git a/meta/recipes-devtools/rust/rust-llvm_1.75.0.bb b/meta/recipes-devtools/rust/rust-llvm_1.75.0.bb
index 4adaf5fbf6d31b1984a81e864285c1e06218e325..b32d3ee38cd2be3fa2dde1b8720f59c0b4b13c90 100644
--- a/meta/recipes-devtools/rust/rust-llvm_1.75.0.bb
+++ b/meta/recipes-devtools/rust/rust-llvm_1.75.0.bb
@@ -56,6 +56,9 @@ EXTRA_OECMAKE = " \
     -DCMAKE_INSTALL_PREFIX:PATH=${libdir}/llvm-rust \
 "
 
+EXTRA_OECMAKE:append:class-native = " -DLLVM_BUILD_LLVM_DYLIB=ON -DLLVM_LINK_LLVM_DYLIB=ON"
+EXTRA_OECMAKE:append:class-nativesdk = " -DLLVM_BUILD_LLVM_DYLIB=ON -DLLVM_LINK_LLVM_DYLIB=ON"
+
 # Forcibly disable the detection of these packages as otherwise
 # it will look at the host Python install
 EXTRA_OECMAKE += "\
@@ -87,6 +90,24 @@ do_install:append () {
     rm -rf "${D}/usr/lib/cmake"
 }
 
+symlink_llvm_libs() {
+    # Create symlinks in ${libdir} so that dynamic libraries can be found in standard paths
+    install -d ${D}${libdir}
+    for lib in ${D}${libdir}/llvm-rust/lib/libLLVM-*.so*; do
+        if [ -e "$lib" ]; then
+            ln -sf llvm-rust/lib/$(basename $lib) ${D}${libdir}/$(basename $lib)
+        fi
+    done
+}
+
+do_install:append:class-native () {
+    symlink_llvm_libs
+}
+
+do_install:append:class-nativesdk () {
+    symlink_llvm_libs
+}
+
 PACKAGES =+ "${PN}-bugpointpasses ${PN}-llvmhello ${PN}-liblto"
 
 # Add the extra locations to avoid the complaints about unpackaged files
@@ -94,7 +115,21 @@ FILES:${PN}-bugpointpasses = "${libdir}/llvm-rust/lib/BugpointPasses.so"
 FILES:${PN}-llvmhello = "${libdir}/llvm-rust/lib/LLVMHello.so"
 FILES:${PN}-liblto = "${libdir}/llvm-rust/lib/libLTO.so.*"
 FILES:${PN}-staticdev =+ "${libdir}/llvm-rust/*/*.a"
-FILES:${PN} += "${libdir}/libLLVM*.so.* ${libdir}/llvm-rust/lib/*.so.* ${libdir}/llvm-rust/bin"
-FILES:${PN}-dev += "${datadir}/llvm ${libdir}/llvm-rust/lib/*.so ${libdir}/llvm-rust/include ${libdir}/llvm-rust/share ${libdir}/llvm-rust/lib/cmake"
+FILES:${PN} += "${libdir}/libLLVM*.so* ${libdir}/llvm-rust/lib/libLLVM*.so* ${libdir}/llvm-rust/lib/libRemarks.so* ${libdir}/llvm-rust/bin"
+FILES:${PN}-dev += "${datadir}/llvm ${libdir}/llvm-rust/include ${libdir}/llvm-rust/share ${libdir}/llvm-rust/lib/cmake"
+
+# Prevent -dev from matching versioned libs ending in .so
+FILES:${PN}-dev:remove = "${libdir}/lib*.so"
+
+# Package unversioned dev symlinks in -dev
+FILES:${PN}-dev += " \
+    ${libdir}/llvm-rust/lib/libLLVM.so \
+    ${libdir}/llvm-rust/lib/libLTO.so \
+    ${libdir}/llvm-rust/lib/libRemarks.so \
+"
+
+# libLLVM-17.so ends in .so; skip dev-so check for host builds
+INSANE_SKIP:${PN}:class-native += "dev-so"
+INSANE_SKIP:${PN}:class-nativesdk += "dev-so"
 
 BBCLASSEXTEND = "native nativesdk"
diff --git a/meta/recipes-devtools/rust/rust_1.75.0.bb b/meta/recipes-devtools/rust/rust_1.75.0.bb
index f037bb33715dc4ba7cbb489ab1599ac6c8c875a4..b11f0ddd2816569e08e6cf908786ee32d49b79e1 100644
--- a/meta/recipes-devtools/rust/rust_1.75.0.bb
+++ b/meta/recipes-devtools/rust/rust_1.75.0.bb
@@ -20,6 +20,11 @@ DEPENDS += "rust-llvm (=${PV})"
 
 RDEPENDS:${PN}:append:class-target = " gcc g++ binutils"
 
+PACKAGECONFIG ??= ""
+PACKAGECONFIG:class-native ??= "llvm-shared"
+PACKAGECONFIG:class-nativesdk ??= "llvm-shared"
+PACKAGECONFIG[llvm-shared] = ",,,"
+
 # Otherwise we'll depend on what we provide
 INHIBIT_DEFAULT_RUST_DEPS:class-native = "1"
 # We don't need to depend on gcc-native because yocto assumes it exists
@@ -128,8 +133,7 @@ python do_configure() {
 
     # [llvm]
     config.add_section("llvm")
-    if d.getVar('PN') == "rust-native":
-        config.set("llvm", "link-shared", e(True))
+    config.set("llvm", "link-shared", e(bb.utils.contains('PACKAGECONFIG', 'llvm-shared', True, False, d)))
     config.set("llvm", "static-libstdcpp", e(False))
     if "llvm" in (d.getVar('TC_CXX_RUNTIME') or ""):
         config.set("llvm", "use-libcxx", e(True))

-- 
2.47.3

Re: [PATCH RFC 0/3] RFC: Fixing rust segfault (#16058) to support Ubuntu 26.04 on Scarthgap

[Alexander Kanavin]

On Fri, 26 Jun 2026 at 13:38, Yoann Congal <yoann.congal@smile.fr> wrote:
> I've hacked the backport until it passes testing:
> https://autobuilder.yoctoproject.org/valkyrie/?#/builders/29/builds/4085
> ... but I'm really *NOT* sure this is the right approach. Hence this RFC
> with the patches I ended-up with.
>
> If anyone could check/review/improve these patches to help me get them
> to a mergable state, that'd be nice. Otherwise, I would have no other
> choice than never support Ubuntu 26.04 on Scarthgap.

I had a quick look, and they're basically ok.

The key check is to run ldd on the rust-native pieces and confirm that
they indeed start linking libLLVM*so dynamically after the patches (if
it comes from rust-llvm, it's probably named differently). E.g. on my
master build:

alex@Zen2:/srv/storage/alex/yocto/build-64-alt$ ldd
tmp/sysroots-components/x86_64/rust-native/usr/lib/librustc_driver-5e2c75e9f7705310.so
    linux-vdso.so.1 (0x00007f8f929d0000)
    libLLVM.so.22.1 => not found
    libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f8f8ca00000)

alex@Zen2:/srv/storage/alex/yocto/build-64-alt$ ldd
tmp/sysroots-components/x86_64/rust-native/usr/bin/rustc
    linux-vdso.so.1 (0x00007f3eee009000)
    librustc_driver-5e2c75e9f7705310.so =>
/srv/storage/alex/yocto/build-64-alt/tmp/sysroots-components/x86_64/rust-native/usr/bin/../lib/librustc_driver-5e2c75e9f7705310.so
(0x00007f3ee8400000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3ee820c000)
    libLLVM.so.22.1 => not found
    libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f3ee7e00000)

Alex

Re: [PATCH RFC 0/3] RFC: Fixing rust segfault (#16058) to support Ubuntu 26.04 on Scarthgap

[Yoann Congal]

On Fri Jun 26, 2026 at 4:57 PM CEST, Alexander Kanavin wrote:
> On Fri, 26 Jun 2026 at 13:38, Yoann Congal <yoann.congal@smile.fr> wrote:
>> I've hacked the backport until it passes testing:
>> https://autobuilder.yoctoproject.org/valkyrie/?#/builders/29/builds/4085
>> ... but I'm really *NOT* sure this is the right approach. Hence this RFC
>> with the patches I ended-up with.
>>
>> If anyone could check/review/improve these patches to help me get them
>> to a mergable state, that'd be nice. Otherwise, I would have no other
>> choice than never support Ubuntu 26.04 on Scarthgap.
>
> I had a quick look, and they're basically ok.
>
> The key check is to run ldd on the rust-native pieces and confirm that
> they indeed start linking libLLVM*so dynamically after the patches (if
> it comes from rust-llvm, it's probably named differently). E.g. on my
> master build:
>
> alex@Zen2:/srv/storage/alex/yocto/build-64-alt$ ldd
> tmp/sysroots-components/x86_64/rust-native/usr/lib/librustc_driver-5e2c75e9f7705310.so
>     linux-vdso.so.1 (0x00007f8f929d0000)
>     libLLVM.so.22.1 => not found
>     libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f8f8ca00000)
>
> alex@Zen2:/srv/storage/alex/yocto/build-64-alt$ ldd
> tmp/sysroots-components/x86_64/rust-native/usr/bin/rustc
>     linux-vdso.so.1 (0x00007f3eee009000)
>     librustc_driver-5e2c75e9f7705310.so =>
> /srv/storage/alex/yocto/build-64-alt/tmp/sysroots-components/x86_64/rust-native/usr/bin/../lib/librustc_driver-5e2c75e9f7705310.so
> (0x00007f3ee8400000)
>     libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3ee820c000)
>     libLLVM.so.22.1 => not found
>     libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f3ee7e00000)

Ok! So that looks good, because with the patches I get:
$ ldd tmp/sysroots-components/x86_64/rust-native/usr/bin/rustc
	linux-vdso.so.1 (0x00007ffc06548000)
	librustc_driver-686d20105d1a2cf7.so => $BUILD/tmp/sysroots-components/x86_64/rust-native/usr/bin/../lib/librustc_driver-686d20105d1a2cf7.so (0x00007fcec0a00000)
	libstd-64729a5a222c378b.so => $BUILD/tmp/sysroots-components/x86_64/rust-native/usr/bin/../lib/libstd-64729a5a222c378b.so (0x00007fcec08c0000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fcec06de000)
	libLLVM-17.so => not found
	libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fcec0400000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fcec4d63000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fcec0320000)
	$BUILD/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007fcec4d98000)

And even: $ oe-run-native rust-native /bin/ldd $BUILD/tmp/work/x86_64-linux/rust-native/1.75.0/recipe-sysroot-native/usr/bin/rustc
Getting sysroot...
	linux-vdso.so.1 (0x00007ffd807b1000)
	librustc_driver-686d20105d1a2cf7.so => $BUILD/tmp/work/x86_64-linux/rust-native/1.75.0/recipe-sysroot-native/usr/bin/../lib/librustc_driver-686d20105d1a2cf7.so (0x00007f9ab0800000)
	libstd-64729a5a222c378b.so => $BUILD/tmp/work/x86_64-linux/rust-native/1.75.0/recipe-sysroot-native/usr/bin/../lib/libstd-64729a5a222c378b.so (0x00007f9ab06c0000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f9ab04de000)
	libLLVM-17.so => $BUILD/tmp/work/x86_64-linux/rust-native/1.75.0/recipe-sysroot-native/usr/bin/../lib/./libLLVM-17.so (0x00007f9aab000000)
	libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f9aaac00000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f9ab04be000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f9ab03de000)
	$BUILD/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f9ab4ae2000)

=> It does, in fact, dynamically link on the built libLLVM-17.so.

Thanks!

>
> Alex


-- 
Yoann Congal
Smile ECS

Re: [PATCH RFC 0/3] RFC: Fixing rust segfault (#16058) to support Ubuntu 26.04 on Scarthgap

[Yoann Congal]

On Fri Jun 26, 2026 at 5:26 PM CEST, Yoann Congal wrote:
> On Fri Jun 26, 2026 at 4:57 PM CEST, Alexander Kanavin wrote:
>> On Fri, 26 Jun 2026 at 13:38, Yoann Congal <yoann.congal@smile.fr> wrote:
>>> I've hacked the backport until it passes testing:
>>> https://autobuilder.yoctoproject.org/valkyrie/?#/builders/29/builds/4085
>>> ... but I'm really *NOT* sure this is the right approach. Hence this RFC
>>> with the patches I ended-up with.
>>>
>>> If anyone could check/review/improve these patches to help me get them
>>> to a mergable state, that'd be nice. Otherwise, I would have no other
>>> choice than never support Ubuntu 26.04 on Scarthgap.
>>
>> I had a quick look, and they're basically ok.
>>
>> The key check is to run ldd on the rust-native pieces and confirm that
>> they indeed start linking libLLVM*so dynamically after the patches (if
>> it comes from rust-llvm, it's probably named differently). E.g. on my
>> master build:
>>
>> alex@Zen2:/srv/storage/alex/yocto/build-64-alt$ ldd
>> tmp/sysroots-components/x86_64/rust-native/usr/lib/librustc_driver-5e2c75e9f7705310.so
>>     linux-vdso.so.1 (0x00007f8f929d0000)
>>     libLLVM.so.22.1 => not found
>>     libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f8f8ca00000)
>>
>> alex@Zen2:/srv/storage/alex/yocto/build-64-alt$ ldd
>> tmp/sysroots-components/x86_64/rust-native/usr/bin/rustc
>>     linux-vdso.so.1 (0x00007f3eee009000)
>>     librustc_driver-5e2c75e9f7705310.so =>
>> /srv/storage/alex/yocto/build-64-alt/tmp/sysroots-components/x86_64/rust-native/usr/bin/../lib/librustc_driver-5e2c75e9f7705310.so
>> (0x00007f3ee8400000)
>>     libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3ee820c000)
>>     libLLVM.so.22.1 => not found
>>     libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f3ee7e00000)
>
> Ok! So that looks good, because with the patches I get:
> $ ldd tmp/sysroots-components/x86_64/rust-native/usr/bin/rustc
> 	linux-vdso.so.1 (0x00007ffc06548000)
> 	librustc_driver-686d20105d1a2cf7.so => $BUILD/tmp/sysroots-components/x86_64/rust-native/usr/bin/../lib/librustc_driver-686d20105d1a2cf7.so (0x00007fcec0a00000)
> 	libstd-64729a5a222c378b.so => $BUILD/tmp/sysroots-components/x86_64/rust-native/usr/bin/../lib/libstd-64729a5a222c378b.so (0x00007fcec08c0000)
> 	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fcec06de000)
> 	libLLVM-17.so => not found
> 	libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fcec0400000)
> 	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fcec4d63000)
> 	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fcec0320000)
> 	$BUILD/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007fcec4d98000)
>
> And even: $ oe-run-native rust-native /bin/ldd $BUILD/tmp/work/x86_64-linux/rust-native/1.75.0/recipe-sysroot-native/usr/bin/rustc
> Getting sysroot...
> 	linux-vdso.so.1 (0x00007ffd807b1000)
> 	librustc_driver-686d20105d1a2cf7.so => $BUILD/tmp/work/x86_64-linux/rust-native/1.75.0/recipe-sysroot-native/usr/bin/../lib/librustc_driver-686d20105d1a2cf7.so (0x00007f9ab0800000)
> 	libstd-64729a5a222c378b.so => $BUILD/tmp/work/x86_64-linux/rust-native/1.75.0/recipe-sysroot-native/usr/bin/../lib/libstd-64729a5a222c378b.so (0x00007f9ab06c0000)
> 	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f9ab04de000)
> 	libLLVM-17.so => $BUILD/tmp/work/x86_64-linux/rust-native/1.75.0/recipe-sysroot-native/usr/bin/../lib/./libLLVM-17.so (0x00007f9aab000000)
> 	libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f9aaac00000)
> 	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f9ab04be000)
> 	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f9ab03de000)
> 	$BUILD/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f9ab4ae2000)
>
> => It does, in fact, dynamically link on the built libLLVM-17.so.

Hmm, it looks like we have the problem but around the bootstraping rustc
compiler:
https://autobuilder.yoctoproject.org/valkyrie/#/builders/4/builds/4033/steps/12/logs/stdio l45466:
|   process didn't exit successfully: `/srv/pokybuild/yocto-worker/genericx86-64/build/build/tmp/work/core2-64-poky-linux/rust/1.75.0/rustc-1.75.0-src/build/bootstrap/debug/rustc [...] (exit status: 254)
| error: rustc interrupted by SIGSEGV, printing backtrace

I checked: it does not dynamically link to libLLVM.so
$ ldd $BUILD/tmp/work/core2-64-poky-linux/rust/1.75.0/rustc-1.75.0-src/build/bootstrap/debug/rustc
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (fr_FR.utf8)
	linux-vdso.so.1 (0x00007fffc78b9000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f50950b2000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f5094ed0000)
	$BUILD/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f509516a000)

I'll pull on that but suggestions welcome!

>
> Thanks!
>
>>
>> Alex


-- 
Yoann Congal
Smile ECS

Re: [PATCH RFC 0/3] RFC: Fixing rust segfault (#16058) to support Ubuntu 26.04 on Scarthgap

[Alexander Kanavin]

On Sat, 27 Jun 2026 at 15:29, Yoann Congal <yoann.congal@smile.fr> wrote:
> Hmm, it looks like we have the problem but around the bootstraping rustc
> compiler:
> https://autobuilder.yoctoproject.org/valkyrie/#/builders/4/builds/4033/steps/12/logs/stdio l45466:
> |   process didn't exit successfully: `/srv/pokybuild/yocto-worker/genericx86-64/build/build/tmp/work/core2-64-poky-linux/rust/1.75.0/rustc-1.75.0-src/build/bootstrap/debug/rustc [...] (exit status: 254)
> | error: rustc interrupted by SIGSEGV, printing backtrace
>
> I checked: it does not dynamically link to libLLVM.so
> $ ldd $BUILD/tmp/work/core2-64-poky-linux/rust/1.75.0/rustc-1.75.0-src/build/bootstrap/debug/rustc
> /bin/bash: warning: setlocale: LC_ALL: cannot change locale (fr_FR.utf8)
>         linux-vdso.so.1 (0x00007fffc78b9000)
>         libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f50950b2000)
>         libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f5094ed0000)
>         $BUILD/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f509516a000)
>
> I'll pull on that but suggestions welcome!

The log is misleading. The actual crash happens in a different, later
rustc, which does link to libllvm statically via librustc_driver:

| error: rustc interrupted by SIGSEGV, printing backtrace
|
| /srv/pokybuild/yocto-worker/genericx86-64/build/build/tmp/work/core2-64-poky-linux/rust/1.75.0/rustc-1.75.0-src/build/x86_64-unknown-linux-gnu/stage1/lib/librustc_driver-cf7d845e2aab959c.so(+0xa75206)
[0x768caf675206]
| /srv/pokybuild/yocto-worker/genericx86-64/build/build/tmp/sysroots-uninative/x86_64-linux/lib/libc.so.6(+0x3b8e0)
[0x768caea4c8e0]
| /srv/pokybuild/yocto-worker/genericx86-64/build/build/tmp/work/core2-64-poky-linux/rust/1.75.0/rustc-1.75.0-src/build/x86_64-unknown-linux-gnu/stage1/lib/librustc_driver-cf7d845e2aab959c.so(+0x637aaa0)
[0x768cb4f7aaa0]
|

Alex

Re: [PATCH RFC 0/3] RFC: Fixing rust segfault (#16058) to support Ubuntu 26.04 on Scarthgap

[Yoann Congal]

On Sat Jun 27, 2026 at 5:16 PM CEST, Alexander Kanavin wrote:
> On Sat, 27 Jun 2026 at 15:29, Yoann Congal <yoann.congal@smile.fr> wrote:
>> [...]
>> I'll pull on that but suggestions welcome!
>
> The log is misleading. The actual crash happens in a different, later
> rustc, which does link to libllvm statically via librustc_driver:
> [...]
> Alex

Thanks Alex, you were right!


To anyone interested in using Ubuntu 26.04 to build scarthgap:
I'm at the point where I need to stop investigating this and drop
Ubuntu 26.04 for scarthgap until someone fixes this situation.

Here is my analysis:
On current scarthgap, rustc links statically to libLLVM (via
librustc_driver). For unclear reasons, when libLLVM comes from recent
distro and rustc is built on old distro, it ends in a segfault.

To fix this, master changed to dynamically link to libLLVM but that is a
major change that I'm not comfortable doing on a stable branch. So, in
this RFC, I've tried limiting the change to -native/nativesdk-. That
does not work because ultimately, target rust does a bootstrap where it
builds a native rustc using target build options (in this case, static
link to libLLVM) and reproduce the segfault.

I thought about using the rust-native we built to bootstrap rust target
but that looks way too intrusive for stable (and also, not trivial!).

One workaround could be to hinder sstate sharing to prevent sharing
accros host distros (opposite of what uninative does), but I don't know
if we could get this idea to a mergeable state.

Finally, support of recent host distros for stable is nice but only as
long as the changes for it are not too intrusive and obey the stable
policy. In this case, I could not not find a fix for this issue that
works under the policy.

Regards,
-- 
Yoann Congal
Smile ECS

Re: [PATCH RFC 0/3] RFC: Fixing rust segfault (#16058) to support Ubuntu 26.04 on Scarthgap

[Sunil Kumar Dora]

On 7/2/2026 7:39 PM, Yoann Congal 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 Sat Jun 27, 2026 at 5:16 PM CEST, Alexander Kanavin wrote:
>> On Sat, 27 Jun 2026 at 15:29, Yoann Congal <yoann.congal@smile.fr> wrote:
>>> [...]
>>> I'll pull on that but suggestions welcome!
>> The log is misleading. The actual crash happens in a different, later
>> rustc, which does link to libllvm statically via librustc_driver:
>> [...]
>> Alex
> Thanks Alex, you were right!
>
>
> To anyone interested in using Ubuntu 26.04 to build scarthgap:
> I'm at the point where I need to stop investigating this and drop
> Ubuntu 26.04 for scarthgap until someone fixes this situation.
>
> Here is my analysis:
> On current scarthgap, rustc links statically to libLLVM (via
> librustc_driver). For unclear reasons, when libLLVM comes from recent
> distro and rustc is built on old distro, it ends in a segfault.
>
> To fix this, master changed to dynamically link to libLLVM but that is a
> major change that I'm not comfortable doing on a stable branch. So, in
> this RFC, I've tried limiting the change to -native/nativesdk-. That
> does not work because ultimately, target rust does a bootstrap where it
> builds a native rustc using target build options (in this case, static
> link to libLLVM) and reproduce the segfault.
>
> I thought about using the rust-native we built to bootstrap rust target
> but that looks way too intrusive for stable (and also, not trivial!).
>
> One workaround could be to hinder sstate sharing to prevent sharing
> accros host distros (opposite of what uninative does), but I don't know
> if we could get this idea to a mergeable state.
>
> Finally, support of recent host distros for stable is nice but only as
> long as the changes for it are not too intrusive and obey the stable
> policy. In this case, I could not not find a fix for this issue that
> works under the policy.


Hi Yoann,

The "unclear reasons" part is now clear. The root cause is a binutils 
linker bug, PR ld/32991.
The full analysis, a small reproducer that checks any ld in seconds, and 
the verification
on both master and scarthgap are available here:

https://bugzilla.yoctoproject.org/show_bug.cgi?id=16058#c86

The related binutils upstream discussion is also linked there.

In short, no Rust changes are needed on scarthgap. The fix is on the 
linker side.
We need to ensure that every ld used to link Rust includes the PR32991 fix.

Would it be feasible to update the workers to use a newer buildtools 
tarball, and to ensure
that workers linking with their host ld also use a linker containing the 
PR32991 fix?

Thanks,
Sunil

>
> Regards,
> --
> Yoann Congal
> Smile ECS
>

Re: [OE-core] [PATCH RFC 0/3] RFC: Fixing rust segfault (#16058) to support Ubuntu 26.04 on Scarthgap

[Alexander Kanavin]

On Sat, 11 Jul 2026 at 19:57, Dora, Sunil Kumar via
lists.openembedded.org
<SunilKumar.Dora=windriver.com@lists.openembedded.org> wrote:
> Would it be feasible to update the workers to use a newer buildtools
> tarball, and to ensure
> that workers linking with their host ld also use a linker containing the
> PR32991 fix?

We're trying to keep the threshold for introducing buildtools high
(I'm aware I'm not always arguing for that, but in principle I agree
with RP :).

The bugzilla ticket mentions that the needed linker fix has been
backported to a lot of older binutils releases, so I'd rather ask them
to update their respective binutils packages. It would perhaps be good
to start a clear list of which distros at which versions need the fix,
which ones already have it, and which ones are covered by buildtools.
Can you look into that? Then we can consider further steps.

Alternatively, perhaps you Sunil could help Yoann to disable static
linking on older rust release which is in scarthgap, e.g. backport the
master fix to the scarthgap. I believe that might be the easiest
option. Yoann tried, but couldn't quite get it to work.

Alex

Re: [PATCH RFC 0/3] RFC: Fixing rust segfault (#16058) to support Ubuntu 26.04 on Scarthgap

[Dora, Sunil Kumar]

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

On Mon, Jul 13, 2026 at 09:30 PM, Alexander Kanavin wrote:

> 
> We're trying to keep the threshold for introducing buildtools high
> (I'm aware I'm not always arguing for that, but in principle I agree
> with RP :).
> 
> The bugzilla ticket mentions that the needed linker fix has been
> backported to a lot of older binutils releases, so I'd rather ask them
> to update their respective binutils packages. It would perhaps be good
> to start a clear list of which distros at which versions need the fix,
> which ones already have it, and which ones are covered by buildtools.
> Can you look into that? Then we can consider further steps.
> 
> Alternatively, perhaps you Sunil could help Yoann to disable static
> linking on older rust release which is in scarthgap, e.g. backport the
> master fix to the scarthgap. I believe that might be the easiest
> option. Yoann tried, but couldn't quite get it to work.

Hi Alex,

Thanks, that makes sense.
Just a quick recap of the master vs. scarthgap situation for anyone following this thread:

Master: Rust already links LLVM dynamically, so neither the worker nor the binutils version matters.

Scarthgap: Rust still links LLVM statically, so the host ld matters. Since the eligible scarthgap
workers use binutils older than 2.45, they do not normally produce the new relocation.
The issue only surfaced after Ubuntu 26.04 was added to the scarthgap pool (241a957),
and was later reverted (3d3e5ff).

Now for the worker check: I don't have access to the workers, so I verified the linker each one
uses in two ways: for host-toolchain workers, I ran that distro's binutils in a Docker image of
the same version; for buildtools workers, I downloaded the exact tarball pinned by the AB and tested
the ld inside it. In each case, I linked the small reproducer and checked whether the
push was converted into a call.

Host-toolchain workers (distro's own ld):

Ubuntu 22.04   - ld 2.38    - BROKEN
Ubuntu 24.04   - ld 2.42    - BROKEN
Ubuntu 25.04   - ld 2.44    - BROKEN
Ubuntu 25.10   - ld 2.45    - ok
Ubuntu 26.04   - ld 2.46    - ok
Debian 12      - ld 2.40    - BROKEN
Debian 13      - ld 2.44    - BROKEN
Fedora 42      - ld 2.44    - BROKEN
Fedora 43      - ld 2.45.1  - ok
Fedora 44      - ld 2.46    - ok
AlmaLinux 10   - ld 2.41    - BROKEN
openSUSE 16.0  - ld 2.45    - ok

Buildtools workers (alma8/9, rocky8/9, stream9, opensuse156,
perf-alma8, debian11) use the pinned tarball's ld:

master    - buildtools 5.1   - ld 2.43.1.20241111 - BROKEN
scarthgap - buildtools 5.0.4 - ld 2.42.0.20240716 - BROKEN

- No distro has picked up the PR32991 backport yet. The "ok" ones simply ship binutils >= 2.45.

- Debian 13, Ubuntu 25.04, and Fedora 42 ship binutils 2.44. Their gas emits plain R_X86_64_GOTPCREL
relocations rather than the GOTPCRELX form introduced in 2.45, so they are fine as producers but
mis-link GOTPCRELX objects produced by >= 2.45 workers.

- Both pinned buildtools tarballs are broken.

So right now every x86 worker except Ubuntu 25.10/26.04, Fedora 43/44 and openSUSE 16.0 links rust
with a broken ld, and those >= 2.45 workers are the producers, so the rest are exposed through shared
sstate.

On next steps:

1. The scarthgap binutils recipe already carries the PR32991 fix (its SRCREV is the backport commit),
so a buildtools tarball rebuilt from current scarthgap would be fine - would refreshing the pinned
tarballs on the helper branches help here?

2. For the host-toolchain workers, if you're okay with it, I can start filing bugs with the relevant
distros (Debian, Ubuntu, and Fedora; the EL rebuilds follow RHEL). The reproducer makes each report
self-contained, but it will still take time for the fixes to land.

3. On the scarthgap backport, I got the dynamic LLVM linking change working with scarthgap's Rust.
Since rust-llvm on scarthgap never built a shared libLLVM, I first had to enable that,
along with some path and packaging adjustments because LLVM 17 installs the shared library
as libLLVM-17.so under the llvm-rust prefix.

The draft is here:
https://git.yoctoproject.org/poky-contrib/commit/?h=deepesh/rust-segfault-scarthgap&id=e8bdd23a09d58e4311988b158ca0b9a63820b723

I built core-image-minimal with Rust and Cargo, booted it, and verified that rustc and cargo work
on the target by compiling and running a test program. librustc_driver now carries a NEEDED entry
for libLLVM-17.so instead of linking LLVM statically. oe-selftest is still running on my side.
If you and Yoann are okay with this approach, I'll submit it to scarthgap once it completes.

~Sunil Dora

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