fix: set CFLAGS to disable bulk-memory for wasm32 C deps

[r-near]

Summary

• Set CFLAGS_wasm32_unknown_unknown="-mno-bulk-memory -mno-bulk-memory-opt" (and CXXFLAGS) in the build environment to prevent C/C++ dependencies from emitting bulk-memory wasm instructions

Problem

LLVM 21+ enables bulk-memory and bulk-memory-opt by default for wasm32-unknown-unknown. This causes C dependencies (e.g., the ring crate) to emit memory.fill/memory.copy instructions, which NEAR's VM rejects with CompilationError(PrepareError(Deserialization)).

Both flags are needed: LLVM 21 split bulk-memory into two separate features, and -mno-bulk-memory alone only disables the first — memory.fill still gets emitted through bulk-memory-opt. See llvm/llvm-project#109443 for related discussion.

Other post-MVP features (sign-ext, mutable-globals) are left enabled as NearVM supports them since protocol 62.

Testing

Verified with the register-contract from defuse-protocol/near-outlayer which depends on ring (C crypto code):

Scenario	Result
clang 18 + this fix	Builds and deploys, identical output to without fix
clang 21 + this fix	Builds and deploys successfully
clang 21 without fix	Fails at wasm-opt with memory.fill errors

Fixes #408

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, you can upgrade your account or add credits to your account and enable them for code reviews in your settings.

[Copilot]

Pull request overview

This PR updates cargo-near-build’s contract build environment to force C/C++ dependencies compiled during cargo near build to target the WebAssembly MVP instruction set, preventing NEAR-incompatible bulk-memory instructions from being emitted by newer LLVM toolchains.

Changes:

• Set CFLAGS="-mcpu=mvp" and CXXFLAGS="-mcpu=mvp" for the wasm build invocation.
• Add env_keys constants for CFLAGS and CXXFLAGS.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
cargo-near-build/src/near/build/mod.rs	Adds default C/C++ compiler flags to the cargo build environment to restrict emitted wasm instructions to MVP.
cargo-near-build/src/env_keys.rs	Introduces env var key constants for CFLAGS and CXXFLAGS.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Setting CFLAGS/CXXFLAGS here will override any flags the user already has in their shell environment for the entire cargo build invocation (not just wasm-target C/C++ compilation). This can break builds that rely on additional CFLAGS or that compile any host-side C code during the build. Consider (a) appending -mcpu=mvp to any existing CFLAGS/CXXFLAGS values instead of replacing them, and/or (b) scoping the flags to the wasm32 target only (so host compilation isn’t affected) while still allowing --env to fully override when needed.

Suggested change

	(env_keys::CFLAGS_ENV, "-mcpu=mvp"),
	(env_keys::CXXFLAGS_ENV, "-mcpu=mvp"),
	("CFLAGS_wasm32-unknown-unknown", "-mcpu=mvp"),
	("CXXFLAGS_wasm32-unknown-unknown", "-mcpu=mvp"),

[frol]

This sounds like a risky and just a coincidental remedy rather a proper fix. This may break reproducible builds verification, so be careful with it.

[r-near]

That's a fair concern. On the reproducibility side though, I verified that for LLVM 18 (where builds already work), the output is bit-for-bit identical with and without the flag — so this shouldn't change anything for existing setups. For LLVM 21, builds fail entirely without it, so there's no existing reproducibility to break. The flags are also scoped to CFLAGS_wasm32_unknown_unknown so host-side C compilation is unaffected.

Happy to hear if you see a better approach though — the core problem is that newer LLVM versions emit bulk-memory instructions from C deps by default, and cargo-near doesn't have a way to prevent that today.