"Thread 'main' panicked" build.rs quit compiling with rp_hal
Opened this issue · 6 comments
I am a rust newbie trying to compile a rust program for target rp2040 (cortexv6-m), and trying to build the cortex-m package 0.7.7 crashes with a panic while trying to copy the static library (build.rs:25). I am using rp_hal because I wish to be able to communicate with rp2040 hardware from my app. The app is building as an app under Apache Nuttx, if that makes any difference.
The error seems very very similar to #271 and my issue may be because I don't use the semihosting module, but my target won't have anything to semihost with.
I can provide more details if needed... can you help?
It's unlikely to be a bug in the cortex-m or cortex-m-rt build.rs script, as it works for many other people. Your best starting point is probably the Rust Embedded Matrix Chat at https://matrix.to/#/#rust-embedded:matrix.org, but people will need to see your source code to work out what is wrong.
I believe this is indeed an issue with cortex-m. The build works ok with the target thumbv6m-none-eabi, and not with thumbv6m-nuttx-eabi, which is the target I want to use and which is considered a supported target by rustc & most crates.
I have verified the failure case by failing with cargo build --target XXX -Zbuild-std in the cortex-m source directory for version 0.7.7, which is the version embedded_hal imports. [That is, it fails when my code is not in scope].
I can see in the current version that the code that falls over -- in build.rs at around line 25 and to do with LTO -- has been removed (by Commit 894f2aa, in Feb 2022).
Please could you issue an update to cortex-0.7.7 so that the recent developments can be taken advantage of?
and which is considered a supported target by rustc & most crates
Ah. thumbv6m-nuttx-eabi is a Tier 3 target, and so is only 'supported' by rustc in the loosest sense (source code exists, it may or may not compile in any given release). Those targets aren't maintained by this Working Group and are not something I think we've ever tested in with these crates, which are designed expressly for thumb*m-none-eabi*.
However.
in build.rs at around line 25
The choice of target probably shouldn't cause build.rs to panic when copying over the precompiled objects bundled in this crate. Those precompiled objects exist (both in LTO and non-LTO form) because we didn't used to have inline assembly and it was the only reasonable way to get instructions like wfi into the code. Do you have more detailed logs about exactly why it was unable to copy the .a file from the bin directory to your target directory?
I'll add doing a cortex-m crate release to the topics for the weekly meeting but I suspect if it was easy we'd have done it already - breaking changes require major version bumps, and major version bumps in ecosystem fundamental software cause massive pains for many many users.
The reason the .a file wasn't copied is that, at least in 0.7.7, it doesn't exist for the -nuttx- target. I have no idea whether it would be reasonable to use a copy of -none- instead? I had a go trying to compile a -nuttx- variant but I was unable to.
I was asking for a new release to be made because it seems some time ago the requirement for these files was dispensed with, and as this work has already been done it seems like a minimal-effort solution.
Ahhh - the files are named after the target? Yes the files are target agnostic so the existing ones should work. The trick is probably using cargo's patch function to redirect use of that crate to a fork with a lightly modified build script so that it works with the NuttX targets.
it seems like a minimal-effort solution
It might seem like it but
I suspect if it was easy we'd have done it already
We definitely don't want to be causing breakage for existing users in the process of adding support for new use-cases.
Let's see what the team says on Tuesday.
Consensus from the meeting seems to be that an 0.7.8 release of cortex-m that rolls up a bunch of non-breaking changes should come soon and will likely solve this.