windows: Spin depends on VC runtime DLL

[lann]

As reported on Discord, it appears that the release builds of spin for Windows require VC runtime DLLs (e.g. VCRuntime140.dll) to be installed.

I think this could be avoided by building with -Ctarget-feature=+crt-static.

[mikkelhegn]

Note on potential legal concerns with static linking, if I understand this note correctly: https://cloud-native.slack.com/archives/C06PC7JA1EE/p1715147783115759?thread_ts=1714665233.820439&cid=C06PC7JA1EE

[itowlson]

@mikkelhegn Could you summarise here please? I don't seem to have access to that link.

[lann]

the spin.exe binary for Windows is not a statically linked binary, but depends on the vcruntime140.dll from VC++ 2015 from Microsoft. This library is not installed by default on Windows, and bundling the C++ compiler runtime is not really possible for legal and technical reasons.

[mikkelhegn]

FYI - The link leads to the CNCF Slack - spinkube channel: https://cloud-native.slack.com

[itowlson]

There seems to be documentation out there on statically linking vcruntime140, including this Rust crate: https://crates.io/crates/static_vcruntime

Do we have any more info on the "legal" reasons why this is not possible? I get that there is a technical issue that a statically linked version wouldn't inherit fixes.

[jandubois]

Do we have any more info on the "legal" reasons why this is not possible?

It is very hard to figure out what and how you can redistribute parts of VC++. The relevant document is probably https://learn.microsoft.com/en-ca/visualstudio/releases/2015/2015-redistribution-vs

The first hurdle is:

"If you have a validly licensed copy of such software, you may copy and distribute with your program the unmodified form of the files listed below, subject to the License Terms for the software."

I don't see how anybody can redistribute the runtime library without having a "validly licensed copy" and having accepted the "License Terms for the software".

Even if it turns out that maybe you are allowed to redistribute, who would risk bundling such files with an open source software release, which doesn't use VC++ to build the release packages? Even if the license for a community edition is available without charge, who is allowed/willing to accept the license terms on behalf of an open source project?

To avoid involving lawyers, you quickly decide to let users download and install the files themselves from Microsoft. But that is a pretty bad user experience, and some people might decide that they don't want to use the software badly enough, if it is that difficult to install it, just to try it out.

The technical issue in redistributing the libraries are high: you can't just bundle the individual DLL, you have to include a "merge module" in your MSI installer, and potentially display a license to the end user during installation.

It also looks like Microsoft is now discouraging the use of redistribution via merge modules and suggest letting Windows handle the installation and updating of redistributable libraries.

---

If all it takes to create a statically linked executable is to stick 2 lines into a config.toml file (from rust-lang/rust#100874):

[target.'cfg(all(windows, target_env = "msvc"))']
rustflags = ["-C", "target-feature=+crt-static"]

then that seems several magnitudes simpler than figuring out the redistribution.

I get that there is a technical issue that a statically linked version wouldn't inherit fixes.

But that is true for any other Rust component you use too; it only gets updated when you recompile the program.

[jandubois]

Note that the same issue applies to the js2wasm plugin as well, while the kube plugin doesn't have any non-system dependencies. I haven't checked any other plugins.

[jandubois]

The relevant document is probably https://learn.microsoft.com/en-ca/visualstudio/releases/2015/2015-redistribution-vs

I did take another look, and it doesn't even mention vcruntime. I've checked the same document for later Visual Studio versions, and they mention vcruntime140d.dll (the debug version, somewhat confusingly located in a debug_noredist directory), but still don't mention the non-debug version.

I'm pretty sure I saw before that they are available as MSI merge modules, but don't want to spend more time researching this, as we for sure won't be bundling those modules with Rancher Desktop.

I get that there is a technical issue that a statically linked version wouldn't inherit fixes.

I think this would still be true if you distribute the DLL with your app: you would still be responsible for updating it yourself. That's why Microsoft discourages you from using the merge-modules, but suggests to use the Microsoft installer, that will install them into the system directories, which will then be updated by Windows Update or Microsoft Update, or whatever it is called nowadays.

---

I also noticed today that you already ship a statically linked version of spin for Linux (e.g. spin-v2.5.0-static-linux-amd64.tar.gz), so there is precedent for shipping both versions.

However, there doesn't seem to be a corresponding static Linux build for the js2wasm plugin, so I wonder how that is supposed to work when you run spin plugin install … (I haven't checked if the plugin maybe already be statically linked).