I got this working relatively easily as a Linux cross-compile with the following mozconfig.

If you package it and unzip it in the windows drive then the build runs just fine, but otherwise it doesn't. It is sorta a WSL issue, but I can work around it by not creating symlinks/hardlinks in $objdir/dist/bin, or removing afterwards like:

#!/usr/bin/env bash

for file in $(find .); do
  f=$(readlink "$file")
  if [ ! -z "$f" ]; then
    f=$(readlink -f "$file");
    rm "$file";
    cp "$f" "$file";
    echo "removed $file -> $f"
  fi
done

With that I get a binary running from Linux, just like the one in the screenshot. ./mach run etc still don't quite work because they pass Linux paths to the WSL exe, which doesn't know how to read them, but that should be fixable.

Ah, I forgot another issue I found, which is that Windows tries to start up firefox looking for mozglue.DLL, but the build will create mozglue.dll. Just cp mozglue.dll mozglue.DLL "fixes" this.

This is interesting, and I'd like to investigate this in the future.
Specifically, I'm wondering how much of an IDE slowdown factor there is when the project is within WSL2.

From glandium on Slack:

At this point it's almost straightforward:

ac_add_options --target=x86_64-pc-mingw32
export WINDOWSSDKDIR="/mnt/c/Program Files (x86)/Windows Kits/10"
export PATH="$PATH:/mnt/c/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.32.31326/bin/Hostx64/x64"

It's not necessarily fast (it would probably be faster with a copy of msvc in WSL rather than on the Windows side via /mnt/c), and you still have to expatriate the build somehow to run it from Windows.

Also, at the moment, it requires the following patch:

--- a/config/rules.mk
+++ b/config/rules.mk
@@ -584,7 +584,7 @@ $(CWASMOBJS):
        $(REPORT_BUILD_VERBOSE)
        $(WASM_CC) -o $@ -c $(WASM_CFLAGS) $($(notdir $<)_FLAGS) $<
 
-WINEWRAP = $(if $(and $(filter %.exe,$1),$(WINE)),$(WINE) $1,$1)
+WINEWRAP = $(if $(and $(filter %.exe,$1),$(WINE)),$(WINE) "$1",$1)
 
 # Windows program run via Wine don't like Unix absolute paths (they look
 # like command line arguments). So when needed, create relative paths

(not needed if your path to MSVC doesn't contain spaces)