Hi all. I'm working on adding resource support to the C# binding generator and making decent progress so far, but I noticed that the runtime tests currently only run on Windows. Is there a fundamental reason for that, or is it just that nobody has gotten around to making them work on other platforms?
I naively tried removing the if cfg!(windows)
check and ran cargo test --no-default-features --features csharp-mono --workspace
, but that errored out because the compiler generated a Windows PE32 csharp-wasm.dll
instead of a Wasm32 csharp-wasm.wasm
. I don't have much .NET experience, so I don't know if this is easy to fix or not. I can boot up an old Windows 10 VM if necessary, but if there's a straightforward way to use either Mac or Linux I'd like to pursue it.
BTW, the codegen tests work fine on MacOS, and I've got the resources.wit
case passing already.
(although I just noticed that the codegen tests also produced Windows PE32 dll
files instead of Wasm files)
Okay, making progress now: I wrapped the csproj.aot();
line in tests/runtime/main.rs in an if cfg!(windows)
which enabled dotnet
to produce a csharp-wasm.wasm
file.
The runtime tests are now building and running, but they're all failing with similar errors:
Error: error while executing at wasm backtrace:
0: 0x8ace - test_imports
at /Users/dicej/p/csharp-wit-bindgen/target/runtime-tests/records/csharp-records/obj/Debug/net9.0/wasi-wasm/wasm/for-build/pinvoke-table.h:563:3
Caused by:
wasm trap: uninitialized element
I'm not sure about mono, but for NativeAOT there are no Linux/MacOS builds of the tools. For Linux this has been because of an inability to use std c++ headers (as required by LLVM headers). However the latest merge should remove that blocker, and we should be able to make progress on Linux tools at least. MacOS is not likely anytime soon as none of the contributors have much interest in that hardware.
Linux support would be great! I just got my (terribly slow) Windows VM set up with EMSDK, etc. and am waiting for the csharp-naot
tests to build and run, so hopefully that works. Meanwhile, I've been digging into the mono tests, and I believe I've traced the root cause back to mono_wasm_load_runtime
not being called, and thus leaving the pinvoke table uninitalized. Is that a known issue? And more broadly, have the csharp-mono
runtime tests in wit-bindgen
ever worked, or was that added aspirationally with the intention that they'll work eventually?
Update: the csharp-naot
tests do work on my Windows VM, so that's what I'll rely on for the time being if I can't get the Mono tests working.
https://github.com/dotnet/runtimelab/issues/1009 I've suggested we use this issue to track the linux build.
There are a couple of issues with the mono tests that started to take a look at and opened Testing tweaks to the csharp-mono project generation by lewing · Pull Request #923 · bytecodealliance/wit-bindgen (github.com) which should get you a bit further along. I'm planning to finish that soon but I'm happy to answer specific questions any time.
Awesome, thanks. I'll keep using the csharp-naot
feature for the time being, but I'll definitely be watching the progress on csharp-mono
.
Last updated: Dec 23 2024 at 13:07 UTC