Update wasmtime (v24.0.0)

[keithmattix]

Builds on top of #404 and #402

[martijneken]

Ran CI. Looks like:

• bazel/dependencies.bzl needs formatting
• diffs in cargo vendor:
  • run bazelisk run //bazel/cargo/wasmsign:crates_vendor -- --repin
  • run bazelisk run //bazel/cargo/wasmtime:crates_vendor -- --repin
  • commit above changes
• CI unhappy (rust panics) with --define engine=v8 and --define engine=wasmtime (might be fixed by above)

[martijneken]

Looks like buildifier and wasmtime remain. Wasmtime build error:

Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
ld.lld: error: undefined symbol: wasm_module_new
>>> referenced by wasmtime.cc
>>>               wasmtime.o:(proxy_wasm::wasmtime::Wasmtime::load(std::__1::basic_string_view<char, std::__1::char_traits<char> >, std::__1::basic_string_view<char, std::__1::char_traits<char> >, std::__1::unordered_map<unsigned int, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::hash<unsigned int>, std::__1::equal_to<unsigned int>, std::__1::allocator<std::__1::pair<unsigned int const, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > > const&)) in archive bazel-out/k8-fastbuild/bin/libwasmtime_lib.a

[keithmattix]

Yep iterating on it locally. I suspect The wasmtime build failure is related to the fact that wasmtime no longer vendors WASM-c-api so I'm figuring out how to make the new pathing with Bazel

[PiotrSikora]

Yep iterating on it locally. I suspect The wasmtime build failure is related to the fact that wasmtime no longer vendors WASM-c-api so I'm figuring out how to make the new pathing with Bazel

wasm-c-api is still vendored in Wasmtime (wheras previously it was imported as git submodule).

[keithmattix]

Looks like CI is pretty much passing except for buildifier (I have the fix staged locally) and this random windows failure. I wonder if it's related to #368 (comment)

[keithmattix]

Getting closer....I tried to repro the Windows issue on a local machine but no dice (rust-lld isn't happy for whatever reason). If anyone has a clue what's happening please let me know. I should also mention that Windows isn't actively supported in Envoy anymore; not sure what proxy-wasm's stance is on Windows

[keithmattix]

Looks like rules_rust no longer aims to support Windows: https://github.com/bazelbuild/rules_rust/blob/main/docs/index.md#supported-platforms. The current Windows failure seems to be a weird interaction with the Windows linker and path escaping: all of the file paths be linked use a combination of backslashes and escaped forward slashes

bazel-out/x64_windows-opt-exec-2B5CBBC6/bin/external/cu__wasmtime-versioned-export-macros-23.0.1\wasmtime_versioned_export_macros-1891060849.wasmtime_versioned_export_macros.92cc13fa569db95f-cgu.[0-9].rcgu.o

but the final error has all forward slashes

note: LINK : fatal error LNK1181: cannot open input file 'bazel-out\x64_windows-opt-exec-2B5CBBC6\bin\external\cu__wasmtime-versioned-export-macros-23.0.1\wasmtime_versioned_export_macros-1891060849.wasmtime_versioned_export_macros.92cc13fa569db95f-cgu.0.rcgu.o'

@PiotrSikora @martijneken @mpwarres can you advise on the support goals for Wasmtime windows in this repo? With Envoy and rules_rust turning down CI, does it make sense to do the same here?

[martijneken]

I don't feel strongly about supporting Wasmtime for Windows, since our dependencies don't support it. Could we keep NullVM on Windows (no Rust, passing) while ditching Wasmtime on Windows (depends on Rust)? @PiotrSikora WDYT

[PiotrSikora]

Could we keep NullVM on Windows (no Rust, passing) while ditching Wasmtime on Windows (depends on Rust)?

There is a big gap here - all Wasm engines other than Wasmtime. Notably, Wasmtime on Windows is the only build on the CI executing real WasmVM code paths (because it is the fastest to compile), so it would be helpful to add tests using another Wasm engine on Windows, before removing Wasmtime on Windows... assuming that you want to support it at all.

cc @shukitchan for ATS, which relies on proxy-wasm-cpp-host.

[keithmattix]

If any other proxy implementations have windows expertise, I'd appreciate the help/guidance!

[PiotrSikora]

Nitpicking as usual, but could this be split into rules_rust update followed by Wasmtime update?

[keithmattix]

Nitpicking as usual, but could this be split into rules_rust update followed by Wasmtime update?

I can give it a try

[keithmattix]

#410 opened. @mpwarres @PiotrSikora @martijneken can one of you kick off CI?

[PiotrSikora]

Could you rebase this on top of main branch and update Wasmtime to v24.0.0? Thanks!

[keithmattix]

CI looks mostly good after the rebase + update. @PiotrSikora @mpwarres @martijneken what's the final verdict on Windows support?

[PiotrSikora]

@PiotrSikora @mpwarres @martijneken what's the final verdict on Windows support?

I think it would be useful to have something working, even if it's not Wasmtime, but I don't have a horse in this race, so the final decision is up to @mpwarres and @martijneken who are the current maintainers.

[mpwarres]

CI looks mostly good after the rebase + update. @PiotrSikora @mpwarres @martijneken what's the final verdict on Windows support?

My individual opinion is that the same considerations that led Bazel and Envoy to drop support for Windows CI (insufficient Windows expertise + lack of resources to track down Windows issues) apply here as well, plus the way that we build Wasmtime depends on rules_rust which no longer supports Windows, so we'd be on shaky ground. I'm in favor of dropping the Wasmtime Windows CI action, but keeping NullVm as a safeguard against total bitrot on Windows, leaving the option of reintroducing support in the future should circumstances change. @martijneken WDYT?

[keithmattix]

Looks like WAMR on windows still passes in CI (confirmed in #413). Can I get some reviews on that and I'll rebase once that merges

[PiotrSikora]

Thanks!

[keithmattix]

@mpwarres @martijneken is this in a good enough state to merge?

[martijneken]

Removed the wasmtime-windows CI action as required. Should be good to merge now.

[PiotrSikora]

This broke builds with --define=engine=multi, see #418.