Rust embedded standard library (no_std) target is not supported about getrandom HOT 9 CLOSED

What target are you compiling your project for? As I wrote in my previous comment, the ESP IDF backend will work only for *-espidf targets.

Since it looks like you are only starting with ESP, I strongly suggest asking help in the esp-rs Matrix server.

For my understanding so far for the no_std environments makes no point using the getrandom library since we have no advantage using it, right?

Depends on whether a dependency in your project uses getrandom or not. If you don't have such dependencies, then you can skip it.

from getrandom.

As explicitly written in the docs, rdrand has effect only on x86 and x86-64 targets.

For WASM targets you either have to use the js feature (and thus depend on wasm-bindgen), or introduce your own custom backend.

from getrandom.

ESP32 systems do not use x86 CPUs and WASM even less relevant. If you are just starting with embedded programming, it may be easier for you to start with ESP IDF, getrandom supports *-espidf targets out of box. If you want to target *-none-elf targets, then you have to write your own custom backend based on the HAL.

from getrandom.

Our target is "riscv32imac-esp-espidf".

Weird. As you can see here compiling for this target should enable backend which uses esp_fill_random.

Double check that your code is indeed compiled for this target. You also could try the following code:

#[cfg(target_os = "espidf")]
compile_error!("Target OS is ESP IDF");
#[cfg(not(target_os = "espidf"))]
compile_error!("Target OS is not ESP IDF");

As you can see here, compiling this code for riscv32imac-esp-espidf should emit the first error message.

from getrandom.

What do you get for the snippet in my previous comment?

It looks like something is wrong with your build configuration. Enabling the custom feature should make the "target is not supported" compilation error impossible.

from getrandom.

Duh. I've missed the crucial part: the error is for getrandom v0.1, not for v0.2. No wonders that setting features for v0.2 had no effect. The best solution would be to update (or patch) dependencies which pull v0.1 to work with v0.2.

from getrandom.

You still depend on getrandom v0.1 as can be clearly seen in the path on your last screenshot. You should find which dependency in your project pulls getrandom v0.1 and patch it to use v0.2 (you can do it by inspecting Cargo.lock or by using cargo tree). If getrandom v0.1 is pulled through an older version of rand, then you should patch dependency which uses it to use rand v0.8.

from getrandom.

Closing this issue since it is caused by getrandom v0.1.

from getrandom.

This issue tracker is probably not the best place to discuss unrelated build issues. Those should generally be brought up on the project specific issue trackers. If there are issues related to getrandom 0.2, feel free to open another issue.

from getrandom.