Windows: support dynamic loading of external/library plugins (re-enable Windows examples CI)
- Dominant language
- Rust
- Stars
- 48
- Forks
- 4
- Avg merge
- 20h 13m
- Merged PRs (30d)
- 11
Description
## Background
External / library plugins (e.g. `waspy` for Python) are installed as Rust `cdylib`s and loaded at runtime via `libloading`.
## Problem
Dynamic plugin loading is currently **compiled out on Windows**. `src/plugin/external.rs` has ~39 `#[cfg(not(target_os = \"windows\"))]` gates, including the `library` field on `ExternalPluginWrapper` and the entire `try_load_library` function. As a result, on Windows `wasmrun compile` of a plugin-based project (e.g. `examples/python-hello`) has no code compiled in to load the plugin `.dll`, so it cannot work even after the plugin is installed.
Related (now fixed): the installer's library-name check assumed `lib.dll`, but Windows `cdylib`s are emitted as `.dll` (no `lib` prefix). This caused `plugin install waspy` to fail on Windows with *"Dynamic library not found after build. Expected libwaspy.{dylib,so,dll}"*. The naming check is fixed, but runtime loading on Windows is still unsupported.
## Impact
`python-hello` (and any external-plugin example) fails on `windows-latest`. The Windows row of the `examples.yml` matrix has been **temporarily disabled** so CI reflects reality.
## TODO
- [ ] Un-gate `libloading` on Windows in `src/plugin/external.rs` (the `library` field, `try_load_library`, symbol resolution, and the remaining `cfg(not(windows))` sites).
- [ ] Verify `wasmrun plugin install waspy` followed by `wasmrun compile examples/python-hello` works on `windows-latest`.
- [ ] Re-add `windows-latest` to the `examples.yml` matrix.
- [ ] Separately verify `c-hello` (emscripten) builds on Windows before re-enabling.
Contributor guide
Assessment
This issue has not been assessed yet.