Skip to content

Errors compiling for ESP32 std #33

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
misterzirillo opened this issue May 15, 2022 · 7 comments
Closed

Errors compiling for ESP32 std #33

misterzirillo opened this issue May 15, 2022 · 7 comments

Comments

@misterzirillo
Copy link

Hello!

I've recently taken a dive into the embedded rust world and have run across a problem. I have cloned this repo https://github.com/ivmarkov/rust-esp32-std-demo and gotten it running on my ESP32-C3-M1 using nightly. However, when I add this dependency I get a compilation error.

 RUST_BACKTRACE=1 cargo build
   Compiling riscv v0.7.0
error: failed to run custom build command for `riscv v0.7.0`

Caused by:
  process didn't exit successfully: `./target/debug/build/riscv-6960dc4cd1ce77dc/build-script-build` (exit status: 101)
  --- stderr
  thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }', ~/.cargo/registry/src/github.com-1ecc6299db9ec823/riscv-0.7.0/build.rs:22:10
  stack backtrace:
     0: rust_begin_unwind
               at /rustc/cb121987158d69bb894ba1bcc21dc45d1e0a488f/library/std/src/panicking.rs:584:5
     1: core::panicking::panic_fmt
               at /rustc/cb121987158d69bb894ba1bcc21dc45d1e0a488f/library/core/src/panicking.rs:142:14
     2: core::result::unwrap_failed
               at /rustc/cb121987158d69bb894ba1bcc21dc45d1e0a488f/library/core/src/result.rs:1785:5
     3: core::result::Result<T,E>::unwrap
               at /rustc/cb121987158d69bb894ba1bcc21dc45d1e0a488f/library/core/src/result.rs:1078:23
     4: build_script_build::main
               at ./build.rs:18:9
     5: core::ops::function::FnOnce::call_once
               at /rustc/cb121987158d69bb894ba1bcc21dc45d1e0a488f/library/core/src/ops/function.rs:248:5
  note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

I realize this library doesn't support riscv yet, however I thought since std is available that it would work anyway.

[dependencies]
shared-bus = { version = '0.2.3', features = ['std'], default-features = false }

Is this possible with a config change? My rust knowledge is very limited at this point.

@Rahix
Copy link
Owner

Rahix commented May 16, 2022

Hm, the error is unclear to me. It stems from this line in the riscv build-script:

https://github.com/rust-embedded/riscv/blob/498924d063b25f46c69d2888743a2f720528c927/build.rs#L22

This does not seem to be related to shared-bus at first glance?

Btw, you do not need any special support for single-threaded bus-sharing. This means can use shared-bus just fine without activating any special features as long as you do not need to access the bus from multiple threads/tasks/execution contexts.

@misterzirillo
Copy link
Author

I can't see how it relates either. When I add shared-bus to my dependencies I get the error, even when no features are enabled. When removed the build succeeds. Something about this crate doesn't agree with that script or vice-versa.

Perhaps this issue belongs in the rust-embedded repo instead? Feel free to close and I'll bring it over there.

@Rahix
Copy link
Owner

Rahix commented May 16, 2022

Yeah, I'd ask over in rust-embedded/riscv, maybe someone over there has an idea... Are you sure it works without shared-bus? I'm really confused how the addition of a crate would make a file in another crate vanish. Maybe try adding the dependencies of shared-bus instead, to see if any of them are to blame? I.e.

embedded-hal = "0.2.3"
nb = "0.1.3"
atomic-polyfill = "0.1.6"

@misterzirillo
Copy link
Author

It seems the problem is with atomic-polyfill. Adding it rather than shared-bus results in the same error. Bumping to newer versions doesn't solve it.

@Rahix
Copy link
Owner

Rahix commented May 17, 2022

Okay, that makes a bit more sense I guess... So maybe try asking over there if they have any idea. In the meantime: We plan to make atomic-polyfill optional in shared-bus anyway (#31) which would then mean you can at least use the crate in some way.

Rahix added a commit that referenced this issue Jun 6, 2022
It turns out the `AtomicCheckMutex` which was the reason for adding
`atomic-polyfill` is currently gated behing the `cortex-m` feature.
Thus we can gate the dependency behind this feature-flag to resolve
issues on other platforms in the meantime.

In the long run, `AtomicCheckMutex` should get its own feature-flag but
for now this is the easiest solution and a non-breaking change.

Ref: #31, #33
@Rahix
Copy link
Owner

Rahix commented Jun 6, 2022

I pushed commit e873193 ("For now, only pull in atomic-polyfill for cortex-m feature") which should help in your case. I will publish a new release shortly.

@misterzirillo
Copy link
Author

Thanks for the update. I'm confident that should do it, at least it did in my fork.

@Rahix Rahix closed this as completed Jul 8, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants