Fix for no_std builds#5
Open
jeddenlea wants to merge 2 commits intomikelodder7:mainfrom
Open
Conversation
"64" isn't a valid `target_arch`.
With the `cdylib` crate type imposed by `Cargo.toml`, it's not possible to include this crate into any others being used in a `no_std` context.
jeddenlea
added a commit
to jeddenlea/zkryptium
that referenced
this pull request
Oct 3, 2024
We need to be able to use this crate in a `no_std` context. Additionally, we cannot make use of the `sha2` or `sha3` crates. This commit adds a couple of features. `std`, which is enabled by default`, must be specified in order to use `write_keypair_to_file`. This was actually the only real dependency on `std`. I've split the `bbsplus` feature up. `min_bbs` enables the algorithms, but does not actually implement either the Sha256 or Shake256 schemes. Just as written, this cannot yet compile into a `no_std` context because bls12_381_plus's no_std support is broken, but I'm trying to resolve that in mikelodder7/bls12_381_plus#5. I've also bumped group to 0.13, which should be nonbreaking because bls12_381_plus 0.8.18 already requires it.
jeddenlea
added a commit
to jeddenlea/zkryptium
that referenced
this pull request
Oct 3, 2024
We need to be able to use this crate in a `no_std` context. Additionally, we cannot make use of the `sha2` or `sha3` crates. This commit adds a couple of features: `std`, which is enabled by default, must be specified in order to use `write_keypair_to_file`. This was actually the only real dependency on `std` outside of tests. I've split the `bbsplus` feature up. `min_bbs` enables the algorithms, but does not actually implement either the Sha256 or Shake256 schemes. Just as written, this cannot yet compile into a `no_std` context because bls12_381_plus's no_std support is broken, but I'm trying to resolve that in mikelodder7/bls12_381_plus#5. I've also bumped group to 0.13, which should be nonbreaking because bls12_381_plus 0.8.18 already requires it.
jeddenlea
added a commit
to jeddenlea/zkryptium
that referenced
this pull request
Oct 3, 2024
We need to be able to use this crate in a `no_std` context. Additionally, we cannot make use of the `sha2` or `sha3` crates. This commit adds a couple of features: `std`, which is enabled by default, must be specified in order to use `write_keypair_to_file`. This was actually the only real dependency on `std` outside of tests. I've split the `bbsplus` feature up. `min_bbs` enables the algorithms, but does not actually implement either the Sha256 or Shake256 schemes. Just as written, this cannot yet compile into a `no_std` context because bls12_381_plus's no_std support is broken, but I'm trying to resolve that in mikelodder7/bls12_381_plus#5. I've also bumped group to 0.13, which should be nonbreaking because bls12_381_plus 0.8.18 already requires it.
jeddenlea
added a commit
to jeddenlea/zkryptium
that referenced
this pull request
Oct 3, 2024
We need to be able to use this crate in a `no_std` context. Additionally, we cannot make use of the `sha2` or `sha3` crates. This commit adds a couple of features: `std`, which is enabled by default, must be specified in order to use `write_keypair_to_file`. This was actually the only real dependency on `std` outside of tests. I've split the `bbsplus` feature up. `min_bbs` enables the algorithms, but does not actually implement either the Sha256 or Shake256 schemes. Just as written, this cannot yet compile into a `no_std` context because bls12_381_plus's no_std support is broken, but I'm trying to resolve that in mikelodder7/bls12_381_plus#5. I've also bumped group to 0.13, which should be nonbreaking because bls12_381_plus 0.8.18 already requires it.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I need to include this crate in a
no_stdbuild, by way of the zkryptium crate. But, this crate fails to build with--no-default-features -F alloc -F groups, because thecdylibtarget is requiring an allocator and panic_handler.Cargo unfortunately does not seem to offer a way to override this attribute of a crate's Cargo.toml file. Unfortunately, while it may appear that
crate_typecan be used as a conditional attribute within the source (https://doc.rust-lang.org/reference/linkage.html), this feature is actually deprecated rust-lang/rust#91632.I can only confirm that this tweak fixes my problem, but I am not sure if it breaks the 32-bit target you were addressing in f4a7732. With this change, I can
cargo buildwithwasm32-unknown-unknownandwasm32-wasip1, but I'm not sure that's enough. Can you please give it a try? I'm happy to adjust this as needed.