Statically link runtime into Windows binary

[itowlson]

Initially setting as draft to get some artifacts (or compile errors) which I can gaze at sternly through my quizzing glass.

Might fix #1504 if it works.

Note that this does not in itself make Rust-based plugins work; any plugins that wanted to run without vcruntime would need to tweak their own builds, which is not necessarily under Spin's control. But we can share the results of this with e.g. SpinKube for their plugin.

[itowlson]

cc @jandubois for visibility

[itowlson]

Binary size goes up from 78.2 MB to 78.4 MB, which doesn't feel like a huge concern. Gonna need to sort out a clean Windows environment to test it though. Roll on Windows Subsystem for Windows!

[itowlson]

I tried the binary on a clean Windows 11 VM (no Rust install, no user-installed vcruntime). Seemed to work fine. On the same VM the Spin 3 release binary failed with the vcruntime error so it is definitely not down to some lurking runtime already on the machine.

[jandubois]

But we can share the results of this with e.g. SpinKube for their plugin.

The kube plugin doesn't have this problem because it is written in Go and doesn't depend on any additional runtime.

The js2wasm plugin however does have the vcruntime dependency (or at least did the last time I looked).

[itowlson]

@jandubois js2wasm is no longer be needed for recent versions of the JS template/SDK. Do you need us to revisit this for customers using older versions?

@dicej Is this likely to be an issue for Windows builds of ComponentizeJS or componentize-py? If so would you be open to me sending a similar PR for those?

[jandubois]

js2wasm is no longer be needed for recent versions of the JS template/SDK.

I was not aware of this. It is still prominently listed in the Fermyon docs: https://developer.fermyon.com/wasm-languages/javascript#js2wasm

Can you point me to some docs that explain at which point the plugin is no longer needed, so we can drop it from Rancher Desktop as well?

Do you need us to revisit this for customers using older versions?

No, we just support a single version of the bundled tools, which are generally the latest stable versions that are compatible with each other at the time of release. This is to make it easy for newcomers to have a good experience before they give up. Experienced users can always manage their own tools if they need to.

[itowlson]

@jandubois It looks like fermyon/developer#1198 is where we removed the Python plugin from our installer. That would be around the Spin 2.4 timeframe. JS was removed in fermyon/developer#1357 which is around Spin 2.7. I can't give you precise Spin docs because the SDKs rev independently of the CLI: the new SDKs should work back to Spin 2.4 if not further, but 2.7 is where I'd feel confident calling the cutoff.

Thanks for flagging the mention in the language guide - I'll get that updated. Sorry for the confusion and the lag on this.

[dicej]

@dicej Is this likely to be an issue for Windows builds of ComponentizeJS or componentize-py? If so would you be open to me sending a similar PR for those?

I don't know for sure, but I believe rustc uses MSVC's link.exe as the default linker, and I'm guessing whatever flags it passes (or does not pass) by default are responsible for the runtime dependency. So yeah, I imagine we'd need to do this for any Rust-based binary we'd care to statically link. PRs to those repos seem appropriate to me.