wasmtime / PR #10890 ci: Use Clang on Windows · git-wasmtime

Stream: git-wasmtime

Topic: wasmtime / PR #10890 ci: Use Clang on Windows

Wasmtime GitHub notifications bot (Jun 09 2025 at 16:53):

MangoPeachGrape edited PR #10890.

Wasmtime GitHub notifications bot (Jun 09 2025 at 17:51):

alexcrichton commented on PR #10890:

CI seems happy, yay! Can you double-check to confirm the binary artifacts of that build are as you expect?

Wasmtime GitHub notifications bot (Jun 09 2025 at 18:30):

jsturtevant commented on PR #10890:

I think using clang here might be a change from dynamically linking the CRT, to statically linking it by default. This could potentially affect other who are expecting it to be dynamically linked.

Would creating two published libraries, one statically linked CRT and one with a dynamically linked CRT also resolve the issue? I guess technically it would be 4, since you need the debug versions of them as well. This appears to be what other tools do as well https://github.com/google/filament/issues/810

Wasmtime GitHub notifications bot (Jun 09 2025 at 18:57):

alexcrichton commented on PR #10890:

Personally I'd fear the amount of infrastructure required to handle the Windows-specific case of producing 4 static libraries when the only real difference between them is how one small C file is compiled amongst them. At that point I'd sort of rather prefer to push on removing the C from Wasmtime entirely to avoid the need to publish 4x more libraries for Windows.

But then again this is still under the murky assumption that for whatever reason /M{D,T}{,d} doesn't seem to apply to Rust-built code. I only really have guesses as to why that might be the case, and for all I know it's not actually valid to build a rust staticlib and expect that to link in C/C++ projects with any of the above flags...

Wasmtime GitHub notifications bot (Jun 09 2025 at 19:27):

MangoPeachGrape commented on PR #10890:

Can you double-check to confirm the binary artifacts of that build are as you expect?

Yes, dumpbin /directives wasmtime.lib gives:
   Linker Directives
   -----------------
   /DEFAULTLIB:uuid.lib
   /DEFAULTLIB:uuid.lib
and with _my_ app it works linking against both the static and the dynamic lib in both debug and release (/MDd and /MD).

clang here might be a change from dynamically linking the CRT, to statically linking

dumpbin /symbols wasmtime.lib outputs snippets like these:
041 00000000 UNDEF  notype       External     | __imp_FreeLibrary
042 00000000 UNDEF  notype       External     | __imp_GetEnvironmentVariableA
043 00000000 UNDEF  notype       External     | malloc
044 00000000 UNDEF  notype       External     | __imp_LoadLibraryExA
045 00000000 UNDEF  notype       External     | free
046 00000000 UNDEF  notype       External     | __imp_GetProcAddress
which I would assume points to it still being linked dynamically, but I might be very wrong?

Wasmtime GitHub notifications bot (Jun 10 2025 at 17:26):

jsturtevant commented on PR #10890:

Personally I'd fear the amount of infrastructure required to handle the Windows-specific case of producing 4 static libraries when the only real difference between them is how one small C file is compiled amongst them. At that point I'd sort of rather prefer to push on removing the C from Wasmtime entirely to avoid the need to publish 4x more libraries for Windows.

makes sense

and with my app it works linking against both the static and the dynamic lib in both debug and release (/MDd and /MD).

interesting, I guess something else is going on then. I don't know the best way to detect if it is static/dynamic in a lib. I've only really ran into this executables.

Wasmtime GitHub notifications bot (Jun 10 2025 at 19:26):

alexcrichton commented on PR #10890:

Ok given that this is all working for @MangoPeachGrape I'm tempted to go ahead and merge this and consider other possible changes in future follow-ups. I hope to one day also remove the last bits of C from Wasmtime eventually too...

@MangoPeachGrape mind updating this PR though to leave a comment in the code itself for why clang is specifically selected? Other than that happy to flag to merge.

Wasmtime GitHub notifications bot (Jun 10 2025 at 20:32):

MangoPeachGrape updated PR #10890.

Wasmtime GitHub notifications bot (Jun 12 2025 at 23:49):

alexcrichton submitted PR review.

Wasmtime GitHub notifications bot (Jun 13 2025 at 00:09):

alexcrichton merged PR #10890.

Last updated: Jan 10 2026 at 02:36 UTC