Build failure when used in Substrate (which requires no_std) project

[vivekvpandya]

My code does not use getrandom directly but though some other creates. It compiles fine normally but when used with in Substrate pallet code it gives me following errors.
error: failed to run custom build command forevercrypt-sys v0.0.8`

Caused by:
process didn't exit successfully: /home/vivek/dev/composable-node-tezos/target/debug/wbuild/node-template-runtime/target/release/build/evercrypt-sys-bf16303d000cf1c6/build-script-build (exit status: 101)
--- stdout
cargo:rerun-if-changed=wrapper.h
cargo:rerun-if-changed=hacl-star

--- stderr
thread 'main' panicked at 'Target '"wasm32-unknown-unknown"' is not supported yet.', /home/vivek/.cargo/registry/src/github.jparrowsec.cn-1ecc6299db9ec823/evercrypt-sys-0.0.8/build.rs:333:14
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

warning: build failed, waiting for other jobs to finish...
error: the wasm32-unknown-unknown target is not supported by default, you may need to enable the "js" feature. For more information see: https://docs.rs/getrandom/#webassembly-support
--> /home/vivek/.cargo/registry/src/github.jparrowsec.cn-1ecc6299db9ec823/getrandom-0.2.3/src/lib.rs:219:9
|
219 | / compile_error!("the wasm32-unknown-unknown target is not supported by
220 | | default, you may need to enable the "js" feature.
221 | | For more information see:
222 | | https://docs.rs/getrandom/#webassembly-support");
| |_________________________________________________________________________^

error[E0433]: failed to resolve: use of undeclared crate or module imp
--> /home/vivek/.cargo/registry/src/github.jparrowsec.cn-1ecc6299db9ec823/getrandom-0.2.3/src/lib.rs:246:5
|
246 | imp::getrandom_inner(dest)
| ^^^ use of undeclared crate or module imp

error: aborting due to 2 previous errors`

Please help how to debug this and fix?

[newpavlov]

Have you read the docs linked in the compilation error message?

[josephlr]

Specifically, you should read https://docs.rs/getrandom/0.2.3/getrandom/#indirect-dependencies

[vivekvpandya]

Does version mentioned in my Cargo.toml and used on other crate needs to be same ?

[josephlr]

Does version mentioned in my Cargo.toml and used on other crate needs to be same ?

Needs to be the same minor version, so just using "0.2" should be fine.

[vivekvpandya]

Thanks for all help! My issue is resolved now. Closing this.

[vivekvpandya]

I am hitting this issue again

    Compiling michelson v0.1.0 (/home/vivek/dev/michelson)
  error: duplicate lang item in crate `sp_io` (which `sp_application_crypto` depends on): `panic_impl`.
    |
    = note: the lang item is first defined in crate `std` (which `getrandom` depends on)
    = note: first definition in `std` loaded from /home/vivek/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/wasm32-unknown-unknown/lib/libstd-473f8d72b377a3bb.rlib
    = note: second definition in `sp_io` loaded from /home/vivek/dev/x-node-tezos/target/debug/wbuild/node-template-runtime/target/wasm32-unknown-unknown/release/deps/libsp_io-beb91e451240264c.rmeta

  error: duplicate lang item in crate `sp_io` (which `sp_application_crypto` depends on): `oom`.
    |
    = note: the lang item is first defined in crate `std` (which `getrandom` depends on)
    = note: first definition in `std` loaded from /home/vivek/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/wasm32-unknown-unknown/lib/libstd-473f8d72b377a3bb.rlib
    = note: second definition in `sp_io` loaded from /home/vivek/dev/x-node-tezos/target/debug/wbuild/node-template-runtime/target/wasm32-unknown-unknown/release/deps/libsp_io-beb91e451240264c.rmeta

[josephlr]

This doesn't seem to be an issue with getrandom. It seems like this sp_io crate conflicts with the definitions in the standard library. For JavaScript targets, getrandom (like many other crates) simply depends on std, we aren't doing anything weird in that regard.

I would open a bug with whoever maintains the sp_io crate.

[vivekvpandya]

I can understand but when I asked this to substrate people they just read "getrandom" in error and ask me to check if it is using std features somehow :(

[josephlr]

Ahhhhhh, so I guess substrate is a no_std target. If that's correct, it means that you can't use the js feature. Do you know if substrate even supports using JavaScript?

If JavaScript isn't supported, you likely want to look into a custom handler, see https://docs.rs/getrandom/0.2.3/getrandom/#custom-implementations (in fact, maybe this is something substrate should provide by default)

[josephlr]

See also paritytech/substrate#5547

[gilescope]

( Generally I'd raise these kind of issues against the substrate repo or reach out on the substrate chat channel: https://matrix.to/#/#substrate-technical:matrix.org - I don't think there's a problem with the getrandom itself.)

[josephlr]

I'm going to close this as it's really an issue which should be raised against the substrate repo. Basically they should either:

• Just provide a no_std compatible custom implementation and then instruct users to register it in their applications like:

// In a user's main.rs
use substrate::substrate_getrandom;
use getrandom::register_custom_getrandom;

register_custom_getrandom!(substrate_getrandom);

• Automatically register their custom implementation as part of one of the core substrate crates

My understanding is that any custom implementation for substrate would just always return an error. This seems fine, and it would be fairly simple to implement:

// In some substrate crate
use core::num::NonZeroU32;
use getrandom::Error;

pub fn substrate_getrandom(buf: &mut [u8]) -> Result<(), Error> {
    let code = NonZeroU32::new(SOME_SUBSTRATE_ERROR_CODE).unwrap();
    Err(Error::from(code))
}

See https://docs.rs/getrandom/0.2.3/getrandom/macro.register_custom_getrandom.html for more information.