Unable to compile with -Z build-std

[illuzen]

Hello,

we are trying to use plonky2 in a substrate chain, and we have proofs verifying when tested in isolation, but we are unable to build the chain as a whole.

If we could compile plonky2 with cargo build -Z build-std --target wasm32-unknown-unknown that would solve our issues. Currently if you try that, you get

error[E0152]: duplicate lang item in crate `core`: `sized`
  |
  = note: the lang item is first defined in crate `core` (which `std` depends on)
  = note: first definition in `core` loaded from plonky2/target/wasm32-unknown-unknown/debug/deps/libcore-1bda2c0fe1509098.rlib,plonky2/target/wasm32-unknown-unknown/debug/deps/libcore-1bda2c0fe1509098.rmeta
  = note: second definition in `core` loaded from .rustup/toolchains/nightly-aarch64-apple-darwin/lib/rustlib/wasm32-unknown-unknown/lib/libcore-ca9fe48a49de91a5.rlib

For more information about this error, try `rustc --explain E0152`.
error: could not compile `plonky2` (bin "generate_constants") due to 1 previous error

Any suggestions?

[illuzen]

ping

[illuzen]

ok new info, compiling with

-Z build-std=std,panic_abort

works across all packages, but =std and =panic_abort do not, they both complain about duplicate versions of core from

/.rustup/toolchains/nightly-aarch64-apple-darwin/lib/rustlib/wasm32-unknown-unknown/lib/libcore-ca9fe48a49de91a5.rlib

and

plonky2/target/wasm32-unknown-unknown/debug/deps/libcore-1bda2c0fe1509098.rlib

Any suggestions guys?

[illuzen]

The real command I want to run is this

env -u CARGO_ENCODED_RUSTFLAGS -u RUSTC CARGO_MAKEFLAGS="-j --jobserver-fds=8,9 --jobserver-auth=8,9" CARGO_TARGET_DIR="..." RUSTFLAGS="-C target-cpu=mvp -C target-feature=-sign-ext -C link-arg=--export-table -Clink-arg=--export=__heap_base -C link-arg=--import-memory --cfg substrate_runtime " SKIP_WASM_BUILD="" "~/.rustup/toolchains/nightly-aarch64-apple-darwin/bin/cargo" "rustc" "--target=wasm32-unknown-unknown" "--manifest-path=..." "--color=always" "--profile" "release" "-Z" "build-std"

[illuzen]

I posted this issue on the rust-lang repo, a reply seems to indicate that it is in fact a bug with -Z build-std

rust-lang/wg-cargo-std-aware#93