Guest build pulls bonsai-sdk → reqwest → rustls → ring; fails to cross-compile for riscv32

[fryorcraken]

Summary

When using spel-framework in a LEZ guest program, the guest target (riscv32im-risc0-zkvm-elf) ends up with bonsai-sdk → reqwest → rustls → ring in its dep graph. ring's build script then fails to cross-compile because riscv32-unknown-elf-gcc rejects -m64:

example_program_deployment_programs:   warning=ring@0.17.14: riscv32-unknown-elf-gcc: error: unrecognized command-line option '-m64'
example_program_deployment_programs:   error: failed to run custom build command for `ring v0.17.14`

A bare LEZ guest (LEZ's own examples/program_deployment with no spel-framework wrapper, just nssa_core + risc0-zkvm) builds cleanly with the same workspace risc0-zkvm config — confirming the chain only appears once spel-framework is added as a dep.

Repro

logos-scaffold new repro --template lez-framework
cd repro
# scaffold uses jimmy-claw/lez-framework by default; swap to logos-co/spel:
#   spel-framework        = git "https://github.com/logos-co/spel.git", branch = "main"
#   spel-framework-core   = ditto
#   spel-client-gen       = ditto
# update guest source: use spel_framework::prelude::*; LezResult → SpelResult; LezOutput → SpelOutput
lgs build

Result: ring build script failure on the guest target.

Dep chain (from cargo tree -p <guest> -i ring)

ring v0.17.14
├── rustls v0.23.40
│   ├── hyper-rustls v0.27.9
│   │   └── reqwest v0.12.28
│   │       └── bonsai-sdk v1.4.2
│   │           └── risc0-zkvm v3.0.5
│   │               └── nssa_core v0.1.0 (logos-execution-zone, tag=v0.2.0-rc1)
│   │                   └── spel-framework-core v0.2.0 (logos-co/spel, main)
│   │                       └── spel-framework-macros v0.2.0
│   │                           └── spel-framework v0.2.0
│   │                               └── <guest>

Root cause

risc0-zkvm 3.0.5 default features are ["client", "bonsai"]. The LEZ workspace declares risc0-zkvm = { version = "3.0.5", features = ['std'] } (defaults left ON). Once spel-framework is in the dep graph, cargo's feature unification activates bonsai for the guest's risc0-zkvm too, dragging the rustls/ring chain into a target that can't compile it.

A workspace-level default-features = false in the consumer's Cargo.toml does not help, because upstream LEZ crates (which spel pulls) declare risc0-zkvm.workspace = true against the LEZ workspace (defaults ON), and feature unification is global.

A bare-LEZ guest avoids this because it doesn't add the spel chain — but it also loses spel's macro ergonomics.

Possible fixes

• Gate spel's nssa transitive risc0-zkvm dep with default-features = false (or a feature flag the guest can opt out of).
• Or have spel surface a "guest-only" feature set that doesn't activate bonsai / client on risc0-zkvm.
• Or upstream a fix to LEZ to disable risc0-zkvm defaults at the workspace level.

Environment

• spel: logos-co/spel main @ ed3bbedb4b684645da05455d30a4a0be7cc4dfe0
• LEZ: logos-blockchain/logos-execution-zone tag v0.2.0-rc1 (35d8df0d)
• risc0-zkvm: 3.0.5
• logos-scaffold: 0.1.1
• Host: Linux 6.19, x86_64

For now I'm proceeding without spel (bare LEZ guest) for my PoC, but happy to test any patch you'd like to try.

[vpavlin]

Investigated. Root cause is the LEZ workspace Cargo.toml enabling risc0-zkvm default features (bonsai, client), which pull in reqwest → rustls → ring.

nssa_core uses risc0-zkvm.workspace = true which inherits these defaults. spel cannot override this via feature flags or workspace dependency overrides because .workspace = true refers to the LEZ workspace, not spel's.

Upstream issue filed: logos-blockchain/logos-execution-zone#468

Workaround: documented in spel README — users must fork LEZ, disable risc0-zkvm defaults, and patch their workspace. Once the upstream fix is merged, the patch can be removed.