Release the newest version of bitvec on crates.io
#5
Comments
github-merge-queue bot
pushed a commit
to paritytech/polkadot-sdk
that referenced
this issue
Feb 6, 2024
This PR improves compatibility with RISC-V and PolkaVM, allowing more runtimes to successfully compile. In particular, it makes the following changes: - The `sp-mmr-primitives` and `sp-consensus-beefy` crates unconditionally required an `std`-only dependency; now they only require those dependencies when the `std` feature is actually enabled. (Our RISC-V target is, unlike WASM, a true `no_std` target where you can't accidentally use stuff from `std` anymore.) - One of our dependencies (the `bitvec` trace) uses a crate called `radium` which doesn't compile under RISC-V due to incomplete autodetection logic in their `build.rs` file. The good news is that this is already fixed in the newest upstream version of `radium`, and the newest version of `bitvec` uses it. The bad news is that the newest version of `bitvec` is not currently released on crates.io, so we can't use it. I've [created an issue](ferrilab/ferrilab#5) asking for a new release, but in the meantime I forked the currently used `radium` 0.7, [fixed the faulty logic](paritytech/radium-0.7-fork@ed66c8a) and used cargo's patching capabilities to use it for the RISC-V runtime builds. This might be a little hacky, but it is the least intrusive way to fix the problem, doesn't affect WASM builds at all, and we can trivially remove it once a new `bitvec` is released. - The new runtimes are added to the CI to make sure their compilation doesn't break.
bgallois
pushed a commit
to duniter/duniter-polkadot-sdk
that referenced
this issue
Mar 25, 2024
This PR improves compatibility with RISC-V and PolkaVM, allowing more runtimes to successfully compile. In particular, it makes the following changes: - The `sp-mmr-primitives` and `sp-consensus-beefy` crates unconditionally required an `std`-only dependency; now they only require those dependencies when the `std` feature is actually enabled. (Our RISC-V target is, unlike WASM, a true `no_std` target where you can't accidentally use stuff from `std` anymore.) - One of our dependencies (the `bitvec` trace) uses a crate called `radium` which doesn't compile under RISC-V due to incomplete autodetection logic in their `build.rs` file. The good news is that this is already fixed in the newest upstream version of `radium`, and the newest version of `bitvec` uses it. The bad news is that the newest version of `bitvec` is not currently released on crates.io, so we can't use it. I've [created an issue](ferrilab/ferrilab#5) asking for a new release, but in the meantime I forked the currently used `radium` 0.7, [fixed the faulty logic](paritytech/radium-0.7-fork@ed66c8a) and used cargo's patching capabilities to use it for the RISC-V runtime builds. This might be a little hacky, but it is the least intrusive way to fix the problem, doesn't affect WASM builds at all, and we can trivially remove it once a new `bitvec` is released. - The new runtimes are added to the CI to make sure their compilation doesn't break.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Could we please get a new release of
bitvecon crates.io?The current version of
bitvecthat's on crates.io usesradium0.7 which has incomplete auto-detection for RISC-V targets, which results in compile time errors for the target I'm using (riscv32ema-unknown-none-elf):The newest versions seems to compile fine, but unfortunately
bitvecwhich uses it is unreleased.The text was updated successfully, but these errors were encountered: