[graial]

Greetings!

Note: This PR is AI-assisted

I'm please to report Ruby's first Internet Computer runtime!

https://xcdhl-gaaaa-aaaal-as2jq-cai.icp0.io/

This is a frontier deployment. I expect this PR to be an ongoing discussion of what (if anything) should be merged.

Status

demo/quickstart - https://gitlab.com/phrug/phrug-icp-demo

• This will be a one command deployment soon enough.

builder repo - https://gitlab.com/phrug/ruby_wasm_builder

• rake-based build system intended to handle constantly changing toolchains, wasi-sdk version-specific linker errors, etc (yet to produce its first build artifact)

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

乾杯!!

[graial]

Oct 30 update - add both full and minimal to build profiles, and also the builder image

This push makes two changes.

1. wasm32-unknown-icp is now registered for both full and minimal. It uses
   BUILD_SOURCES.product(BUILD_PROFILES), mimicking
   wasm32-unknown-wasip1. The fork publishes a prebuilt static library per
   Build, and its next publication is full. So the icp tasks double, from 5 to
   10. I held off on this because I wasn't sure if I would exceed the IC-runtime's size limits with full (by including OpenSSL, libyaml and zlib).

2. CI builds icp by copying the wasm32-unknown-wasip1 builder image. Prior versions of this PR had failing CI jobs, because builders/wasm32-unknown-icp
   did not exist. the target triple is now an explicit alias of wasm32-unknown-wasip1, with the same --host, toolchain and flags. So rakelib/ci.rake maps it to wasip1's image instead of adding a builder of its own.

   If you'd prefer the convention wasm32-unknown-wasip2 follows, a copied
   builders/wasm32-unknown-icp, I'm happy to switch. I avoided it because it
   would be an image that could drift from the one it aliases.

I believe that the remaining failing Compile native gem for arm-linux-musl check is unrelated to any of my changes.