Deku doesn't compile on ESP32 no-std
yanshay opened this issue · comments
I'm trying to use Deku on ESP32 no-std, and it doesn't compile. (on std it does work fine)
I added it as instructed to Cargo.toml as
deku = { version = "0.16", default-features = false, features = ["alloc"] }
And I get the error below.
I searched for resolution and I found it is not uncommon with certain targets due to versioning of rust/radium, I've seen all kinds of related bugs elsewhere being closed long time ago, tried using all kinds of features on radium/bitvec but couldn't get this solved.
I think it has to do with bitvec still using an old version of radium that decides on which Atomics are available based on all kinds of heuristics and it doesn't recognize them all, but couldn't find any way to force it in in any way to understand Atomic64 is not available for my target.
Any ideas how to resolve this? I don't mind any hacky solution since it practically means all the work I've done can't be used on the target I planned on using.
Compiling radium v0.7.0
error[E0432]: unresolved imports `core::sync::atomic::AtomicI64`, `core::sync::atomic::AtomicU64`
--> /Users/yanivshaya/.cargo/registry/src/index.crates.io-6f17d22bba15001f/radium-0.7.0/src/lib.rs:53:34
|
53 | use core::sync::atomic::{AtomicI64, AtomicU64};
| ^^^^^^^^^ ^^^^^^^^^ no `AtomicU64` in `sync::atomic`
| |
| no `AtomicI64` in `sync::atomic`
|
help: a similar name exists in the module
|
53 | use core::sync::atomic::{AtomicI32, AtomicU64};
| ~~~~~~~~~
help: a similar name exists in the module
|
53 | use core::sync::atomic::{AtomicI64, AtomicU32};
| ~~~~~~~~~
I found a way to get this to compile by adding to Cargo.toml:
[patch.crates-io]
bitvec = {git = "https://github.com/arctic-alpaca/ferrilab"}
This forces project to use a fork of bitvec
that has been updated to use a new version of radium
.
Looks like artic-alpaca has already notified the bitvec author ferrilab/bitvec#214.
The bitvec library has not been maintained for more than half a year now, the issue was closed and there's no activity since. ferrilab/bitvec#220 seems like a good alternative?