error: the crate panic_abort does not have the panic strategy abort
#343
Comments
|
One method to handle this is to append |
|
I'm seeing this if I set |
|
ah nevermind. I tried to set up a minimal build and it worked. |
|
adding |
|
even with the simplest hello world with panic abort is not working |
|
@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 [1] https://git.yoctoproject.org/poky/tree/meta/recipes-devtools/rust/libstd-rs.inc#n22 |
|
I have built a number of things against Kirkstone without issue, and no need to override anything. Example Kirkstone recipe: Requires only bbappend (proc2 workaround): |
|
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 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 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. |
These are now deadlinks. |
|
@moto-timo Hi Tim. 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 :) |
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 @ 02db606
Version(s) of poky and/or oe-core
poky - dunfell @ 320f059a9b7d7cf9b493778933469d5c604be42b
Expected result
websocatbuilds without errorsActual result
websocatfails to build:Steps to reproduce
cargo bitbakewebsocatincludes this in Cargo.toml:If I comment
panic = 'abort'out, then the recipe builds cleanly.Here is the recipe I generated:
The text was updated successfully, but these errors were encountered: