Open jordemort opened 3 years ago
One method to handle this is to append RUST_PANIC_STRATEGY = "abort"
to your local.conf and rebuild the recipe. It will re-trigger build of rust-native, cargo-native, and libstd-rs. The default strategy is set for unwind
I'm seeing this if I set RUST_PANIC_STRATEGY
to abort in local.conf on x86-64 (or if the crate sets it). But it is working on arm64. I was able to reproduce it on master with poky master and the rust-hello-world recipe.
ah nevermind. I tried to set up a minimal build and it worked.
adding RUST_PANIC_STRATEGY = "abort"
to local.conf did not work for me
even with the simplest hello world with panic abort is not working https://github.com/frankplus/rust-hello-world
@frankplus I believe my suggestion was for 1.51. what version/branch are you having trouble with? Also honister implements rust in OE-core, so if you can replicate there Yocto list can help.
The problem appears on both dunfell (with meta-rust) and honister (with rust in oe-core)
Part of this seems to stem from the cargo features set in libstd [1] enabling panic_unwind in the std crate [2]. By setting CARGO_FEATURES = "backtrace"
in my local.conf I was able to get past this but I haven't verified if the panic behavior is working.
[1] https://git.yoctoproject.org/poky/tree/meta/recipes-devtools/rust/libstd-rs.inc#n22 [2] https://github.com/rust-lang/rust/blob/master/library/std/Cargo.toml#L59
I have built a number of things against Kirkstone without issue, and no need to override anything.
Example Kirkstone recipe: https://github.com/meta-flutter/meta-flutter/blob/kirkstone/recipes-devtools/membrane/membrane-dart-example_git.bb
Requires only bbappend (proc2 workaround): https://github.com/meta-flutter/meta-flutter/blob/kirkstone/recipes-devtools/rust/libstd-rs_%25.bbappend
I don't see an attempt to use abort as the panic mechanism in that example, but I might be missing it.
Another observation is that this build time issue occurs for x86-64 target arch but not arm64.
Building with kirkstone I don't have to set the strategy, as the strategy defaults to unwind
: https://git.openembedded.org/openembedded-core/tree/meta/classes/rust-common.bbclass?h=kirkstone#n14
Changing the strategy affects all rust recipes in the image. Using panic abort leaves no cookie crumbs in the syslog, which is why unwind is preferred. So my point is that with kirkstone tip of tree, it should just work.
For kirkstone dynamic layers aren't used for rust recipes, as it's now part of oe-core.
That's a good point, my suggestion is definitely a hack. This issue is coming up when a crate sets its panic to abort which they may or may not have a good reason to set. Mozjs just patched out panics in the Cargo.toml file, but that might not work for every situation.
Websocat, from the OP, set's it's panic type: https://github.com/vi/websocat/blob/master/Cargo.toml#L112 Firecracker, provided in meta-aws, does too: https://github.com/firecracker-microvm/firecracker/blob/main/Cargo.toml#L9
My understanding for a normal rustup setup is they ship a pre-built std library, so I'm not really clear why this cargo feature setting matters. I'm mostly bumping into the std-aware cargo workgroup, the rustc development manual and some nightly features when I search for this.
Yes I contributed the firecracker recipe to meta-aws, so I'm pretty familiar with it.
I have built a number of things against Kirkstone without issue, and no need to override anything.
Example Kirkstone recipe: https://github.com/meta-flutter/meta-flutter/blob/kirkstone/recipes-devtools/membrane/membrane-dart-example_git.bb
Requires only bbappend (proc2 workaround): https://github.com/meta-flutter/meta-flutter/blob/kirkstone/recipes-devtools/rust/libstd-rs_%25.bbappend
These are now deadlinks.
@moto-timo Hi Tim. I recently removed the membrane-dart-example due to upstream issue, but it can be found here: https://github.com/meta-flutter/meta-flutter/blob/e08c45c6b8c961734e7be9745e0f1ea344fa5ea8/dynamic-layers/clang-layer/recipes-devtools/membrane/membrane-example_git.bb
The bbappend was removed as Proc2 issue goes away with Scott's Rust toolchain mix-in (1.69+). So I opted to let people manage their own pain :) https://github.com/meta-flutter/meta-flutter/blob/e08c45c6b8c961734e7be9745e0f1ea344fa5ea8/recipes-devtools/rust/libstd-rs_%25.bbappend
I recently removed the membrane-dart-example due to upstream issue, but it can be found here: https://github.com/meta-flutter/meta-flutter/blob/e08c45c6b8c961734e7be9745e0f1ea344fa5ea8/dynamic-layers/clang-layer/recipes-devtools/membrane/membrane-example_git.bb
This recipe can be greatly simplified by using the cargo-update-recipe-crates.bbclass. I'm also trying to find the time to add knowledge of that bbclass into devtool/recipetool so the Auto Upgrade Helper (AUH) will be aware of it. Baby steps.
@moto-timo I'll check it out. I have a number of very complicated rust recipes. One has over 800 crates, curious how the helper bbclass will fare.
This has been my go-to pattern (generic non-multipass repos):
The multi-pass like this membrane recipe uses llvm and dart for native pass (code gen), then native build artifacts for target pass. It looks like the referenced bbclass may replace my root-pkg-ws tool. That would be nice. I'm all for making the Yocto rust support better!
Version(s) of meta-rust
master @ 02db606a9678bddf81169a3f2e7c6346e0876839
Version(s) of poky and/or oe-core
poky - dunfell @ 320f059a9b7d7cf9b493778933469d5c604be42b
Expected result
websocat
builds without errorsActual result
websocat
fails to build:Steps to reproduce
cargo bitbake
websocat
includes this in Cargo.toml:If I comment
panic = 'abort'
out, then the recipe builds cleanly.Here is the recipe I generated: