Trying to pack ruby for icp

[graial]

Greetings!

Note: This bug report and fix is AI-assisted

I decided to try and deploy Rails to Internet Computer. So this is a frontier deployment.

Status

Opening a dialogue, not seeking merge. Depends on #666 , the target-handling
fix, which is hopefully ok to merge.

What changed since the original description

The original PR took the simple, naive approach to adapt the Emscripten toolchain.
This updated wasm32-unknown-icp target uses wasi-sdk. RubyWasm::Icp subclasses RubyWasm::WASISDK and only overrides name.

What this PR contains

• Icp < WASISDK, overriding name.
• A Toolchain.get passing build_dir and wasi_sdk_version (same as wasip1).
• --host wasm32-wasi for the target in product.rb#system_triplet_args, matching every other wasi-sdk target. A bare --host wasm32 produces a build that succeeds with mis-detected features and a subtly wrong rbconfig.
• A minimal entry in the Rakefile build matrix. full is deliberately absent: the stdlib depends on an unresolved filesystem question downstream, so I am deferring the attempt at a full until I have minimal on a working canister.

No change to crossruby.rb. An earlier version of this PR carried an
icp-specific when arm there; #666 removes that requirement.

What the target produces

libruby-static.a and headers only. for use in running the POC deployment lives here

A canister is a reactor with entry points named canister_init and
canister_update <name>, not a command with _start. Producing one requires a C shim that exports those, links ic-wasi-polyfill, and defines a Candid interface. None of that belongs in ruby.wasm: entry points imply an
interface, and a generic eval : (text) -> (text) endpoint would ship a
canister that executes arbitrary Ruby from any principal at the deployer's
expense.

So the target stops at the library, and the downstream steps are documented
at ruby_wasm_builder.

Parity of outputs to existing builds

There are no compile-time differences between wasm32-unknown-icp and
wasm32-unknown-wasip1 today. Building both at 3.3-...-minimal and comparing the resulting libruby-static.a gives identical defined symbol sets, 18,606 symbols.

The archives are not byte-identical, due to filepath differences which get baked into the debug info. The configure invocations differ only in --host-adjacent naming; both receive the same wasi-sdk compiler, the same four _WASI_EMULATED_* defines, and the same ac_cv_func_* overrides.

So this triple exists so the IC can diverge later. We have not identified any IC-specific flags yet.

Open questions for maintainers

• Is a target that emits only a static library acceptable?
• Is wasm32-unknown-icp the right name? wasm32-wasip1-icp would signal the sysroot relationship more clearly.
• Given the archives are equivalent today, is a distinct triple the right vehicle at all, or is this better as documentation until a compile-time difference actually exists?

Context

• Forum thread on the missing WASI implementation:
  https://forum.dfinity.org/t/wasi-snapshot-preview1-equivalent/72239
• ic-wasi-polyfill: https://github.com/wasm-forge/ic-wasi-polyfill
• wasi2ic: https://github.com/wasm-forge/wasi2ic

乾杯!!