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 <[email protected]> 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
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#240720):
https://lists.openembedded.org/g/openembedded-core/message/240720
Mute This Topic: https://lists.openembedded.org/mt/119988126/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
