Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compilation errors on 5.0.0-alpha.1 #1125

Closed
morgsmccauley opened this issue Dec 20, 2023 · 2 comments
Closed

Compilation errors on 5.0.0-alpha.1 #1125

morgsmccauley opened this issue Dec 20, 2023 · 2 comments

Comments

@morgsmccauley
Copy link

morgsmccauley commented Dec 20, 2023

Due to compilation on 4.1.1 also being broken (#1119) I opted to upgrade and try 5.0.0-alpha.1. I was able to successfully compile but ran in to several issues, happy to help out with fixing these but not sure where those fixes are best placed.

getrandom

This crate must be installed with the js feature. It looks like it currently is but is only listed as a dev dependency. I guess it should be moved to an actual dependency?

 │ error: the wasm*-unknown-unknown targets are not supported by default, you may need to enable the "js" feature. For more information see: https://docs.rs/getrandom/#webassembly-support
 │    --> /Users/morganmccauley/.cargo/registry/src/index.crates.io-6f17d22bba15001f/getrandom-0.2.11/src/lib.rs:290:9
 │     |
 │ 290 | /         compile_error!("the wasm*-unknown-unknown targets are not supported by \
 │ 291 | |                         default, you may need to enable the \"js\" feature. \
 │ 292 | |                         For more information see: \
 │ 293 | |                         https://docs.rs/getrandom/#webassembly-support");
 │     | |________________________________________________________________________^
 │ 
 │ error[E0433]: failed to resolve: use of undeclared crate or module `imp`
 │    --> /Users/morganmccauley/.cargo/registry/src/index.crates.io-6f17d22bba15001f/getrandom-0.2.11/src/lib.rs:346:9
 │     |
 │ 346 |         imp::getrandom_inner(dest)?;
 │     |         ^^^ use of undeclared crate or module `imp`

As a workaround this can be fixed by adding the crate locally:

getrandom = { version = "0.2", features = ["js"] }

MacOS Clang

The version of clang which ships with MacOS doesn't support the wasm32-unknown-unknown build target, this didn't seem to be an issue in previous versions.

 │   exit status: 1
 │   running: "clang" "-O0" "-ffunction-sections" "-fdata-sections" "-fPIC" "-g" "-fno-omit-frame-pointer" "--target=wasm32-unknown-unknown" "-I" "depend/secp256k1/" "-I" "depend/secp256k1/include" "-I" "depend/secp256k1/src" "-I" "wasm/wasm-sysro
ot" "-I" "wasm/wasm-sysroot" "-Wall" "-Wextra" "-DSECP256K1_API=" "-DENABLE_MODULE_ECDH=1" "-DENABLE_MODULE_SCHNORRSIG=1" "-DENABLE_MODULE_EXTRAKEYS=1" "-DECMULT_GEN_PREC_BITS=4" "-DECMULT_WINDOW_SIZE=15" "-DUSE_EXTERNAL_DEFAULT_CALLBACKS=1" "-DEN
ABLE_MODULE_RECOVERY=1" "-o" "/Users/morganmccauley/Developer/queryapi/registry/contract/target/wasm32-unknown-unknown/debug/build/secp256k1-sys-9da0620a6319fd3c/out/wasm/wasm.o" "-c" "wasm/wasm.c"
 │   cargo:warning=error: unable to create target: 'No available targets are compatible with triple "wasm32-unknown-unknown"'

To resolve this, brew install llvm and use the clang binary included to build:

CC="/opt/homebrew/Cellar/llvm/17.0.6/bin/clang" cargo near build --no-abi

near-primitives on 32-bit targets

As described in near/nearcore#7406, compilation of near-primitives errors out when targeting 32-bit machines:

 │ error[E0308]: mismatched types
 │     --> /Users/morganmccauley/.cargo/registry/src/index.crates.io-6f17d22bba15001f/near-primitives-0.17.0/src/rand.rs:66:50
 │      |
 │ 66   |         let uniform_index = usize::from_le_bytes(usize_seed) % self.aliases.len();
 │      |                             -------------------- ^^^^^^^^^^ expected an array with a fixed size of 4 elements, found one with 8 elements
 │      |                             |
 │      |                             arguments to this function are incorrect
 │      |
 │ note: associated function defined here
 │     --> /Users/morganmccauley/.rustup/toolchains/1.70.0-aarch64-apple-darwin/lib/rustlib/src/rust/library/core/src/num/mod.rs:1166:5
 │      |
 │ 1166 | /     uint_impl! {
 │ 1167 | |         Self = usize,
 │ 1168 | |         ActualT = u32,
 │ 1169 | |         SignedT = isize,
 │ ...    |
 │ 1183 | |         bound_condition = " on 32-bit targets",
 │ 1184 | |     }
 │      | |_____^
 │      = note: this error originates in the macro `uint_impl` (in Nightly builds, run with -Z macro-backtrace for more info)

To fix, the function (sample()) can be updated to just return 0, bypassing the erroneous use of usize, but I'm not sure this is safe to do in this context. It doesn't look like near-sdk uses WeightedIndex so probably?

@frol
Copy link
Collaborator

frol commented Dec 22, 2023

@morgsmccauley

getrandom is not supported in wasm. Use near-rng

MacOS Clang: I cannot reproduce it on my MacOS ARM (M1). I would guess that you had some other llvm previously installed with brew.

image

To test I run the following commands:

cargo near new qq
cd qq
cargo near build --no-abi

near-primitives on 32-bit targets: You should not compile near-primitives to wasm32, they won't work. Review your dependencies and ensure that you don't pull it into non-dev-dependencies.

@morgsmccauley
Copy link
Author

morgsmccauley commented Jan 3, 2024

Thanks @frol! Looks like all these problems were related to the compilation of near-primitives. Removing the dependency has resolved them :).

morgsmccauley added a commit to near/queryapi that referenced this issue Jan 4, 2024
This PR adds the `created_at_block_height` and `updated_at_block_height`
fields to `IndexerConfig` within the registry contract. The motive
behind this is to provide Coordinator V2 with a way for comparing the
actual and desired states of the system, i.e. if there is a mismatch
between the registry and the system, action should be taken. Without
versions, there is no way of making this comparison.

## Compilation Errors
~~I ran in to several issues trying to compile the `wasm32` binary, and
have outlined all these issues in
near/near-sdk-rs#1125, as well as in the
`README.md` so that the fixes are documented. These fixes are a bit
janky, but I've tested the deployed contract and all seems to be ok.~~

These have been resolved, see:
#458 (comment)

## Account Roles Migration
I've also included `account_roles` in this migration as we have some
incorrect accounts as `Owner`s (`pavelnear.near`). All owners will be
wiped and re-written from the contract default state. All `User`s will
remain.

## Coordinator V1
Coordinator V1 has been tested to ensure that it can still parse the
registry after these new fields have been applied.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants