- download --list-workloads / --list-components print every workload or component id (with its manifest title) without downloading anything, for discovering what to pass as a package id or --with-* toggle. - download --print-deps-tree prints the dependency tree of whatever the current flags would actually select, sharing the exact same arch/--ignore/Optional/Recommended filtering ExpandSelection uses so the output matches a real download; diamond dependencies are shown once and referenced as "(see above)" afterwards to keep it finite. - Fixed --manifest (offline/predownloaded manifest testing) never having worked at all: it builds a "file:" URL but the shared http.Client had no handler registered for that scheme. - Added a CI workflow running gofmt/vet/build/test on every push and PR; previously only the tag-triggered release workflow existed.
5.6 KiB
msvc-go-wine
Cross compile with MSVC on Linux, using Wine — a single-binary Go tool inspired by mstorsjo/msvc-wine's approach (download the real MSVC/WinSDK, wrap the compiler under Wine), implemented independently.
Once installed, you invoke the real Microsoft toolchain exactly like on
Windows: cl, link, lib, rc, midl, mt, dumpbin, msbuild,
nmake, ml, ml64, armasm, armasm64 all just work from your PATH.
How it works
msvc-go-wine is one Go binary that behaves differently depending on the
name it's invoked as (a "multi-call binary", like busybox):
- Invoked as
cl,link,lib, ... → it loads a small per-architectureenv.json, builds theINCLUDE/LIB/WINEPATHenvironment Wine needs, rewrites absolute unix paths in the arguments into Wine'sz:\...form (working around a Wine/cl.exe include-path bug), runs the real.exeunderwine/wine64, and rewrites the tool's output back fromz:\...paths to plain unix paths so your build system's error parsing keeps working. - Invoked as
msvc-go-wine→ it exposes thedownload,install,envandversionmanagement subcommands described below.
Quick start
# 1. Download and unpack MSVC + Windows SDK into ~/.msvc-go-wine (requires
# accepting Microsoft's Visual Studio Build Tools license, and msitools
# for unpacking .msi payloads). Pass --dest <dir> for a different location.
msvc-go-wine download --accept-license
# 2. Wire up the tool wrappers
msvc-go-wine install
# 3. Add the toolchain to PATH and build
export PATH=~/.msvc-go-wine/bin/x64:$PATH
cl /nologo /EHsc hello.cpp
Prerequisites
wine(orwine64) — runs the realcl.exe/link.exe/etc.msitools(msiextract) — unpacks the.msipayloads MSVC/WinSDK ship as.git— used to apply the small compatibility patches bundled withdownload(see Compatibility patches below).
On ALT Linux:
pkcon install wine msitools
Commands
msvc-go-wine download --accept-license [--dest <dir>] [options] fetch and unpack MSVC/WinSDK
msvc-go-wine install [dir] wire up wrappers for a downloaded MSVC
msvc-go-wine env --bin <dir>/bin/<arch> print INCLUDE/LIB for native clang-cl/lld-link use
msvc-go-wine version print the version
--dest/[dir] both default to ~/.msvc-go-wine when omitted.
download supports --msvc-version, --sdk-version, --architecture,
--host-arch, --with-* component toggles, --ignore, --only-download,
--only-unpack, --keep-unpack, --cache, --language,
--include-optional, --skip-recommended, --major, --preview,
--manifest, --list-workloads, --list-components, --print-deps-tree.
Run msvc-go-wine download -h for the full list.
--list-workloads/--list-components print every workload/component id
(with its human-readable title) available in the fetched manifest and exit
without downloading anything - useful for discovering what to pass as a bare
package id or via --with-*. --print-deps-tree prints the dependency tree
of whatever would actually be selected (honoring every other flag), also
without downloading.
Using clang-cl/lld-link instead of Wine
You don't need Wine at all if you drive the (nonredistributable) MSVC/WinSDK headers and libraries with Clang/LLD in MSVC-compatible mode:
eval "$(msvc-go-wine env --bin ~/.msvc-go-wine/bin/x64)"
clang-cl -c hello.c
lld-link hello.obj -out:hello.exe
Building from source
go build -o msvc-go-wine ./cmd/msvc-go-wine
Go 1.23+ is all you need to build it; wine/msitools are only needed at
run time (install/tool invocation and download respectively).
toolrelay.exe
install compiles assets/vendor/toolrelay.cpp (a small native Windows
launcher, original to this project) with the freshly-installed host-arch
cl.exe (best-effort: if wine isn't present yet, or the compile fails,
install still succeeds and the wrapper runtime just falls back to invoking
tools directly through wine). When present, every non-MSBuild tool
invocation is routed through it via two named FIFOs. This is what lets
mt.exe's CMake-compatibility exit-code translation (0x41020001 → 0xbb)
survive Wine's own exit-code truncation: only a native Windows process
observing the untranslated code via GetExitCodeProcess() can catch it
before Wine marshals the process exit back to Unix and drops everything but
the low byte.
Compatibility patches
download applies a handful of small patches (assets/patches) to the
downloaded MSVC/WinSDK tree - independently written for this project - that
make VsDevCmd.bat and MSBuild's SDK-detection props work without a
Windows Registry (which doesn't exist under Wine): they check the SDK
directly under the VS install root instead of querying the registry, skip
telemetry, and don't hard-fail devcmd setup when an optional component
(ConnectionManagerExe, bundled CMake/Ninja) wasn't downloaded.
Known gaps
downloaddoesn't yet support installing the Windows Driver Kit via--with-wdk-installers; the core selection/download/unpack/install pipeline, dependency tree printing, and workload/component listing are all fully implemented.
License
MIT, see LICENSE.txt - covers msvc-go-wine's own source only.
The MSVC Build Tools / Windows SDK that download fetches remain governed
by Microsoft's own license (accepted via --accept-license), same as with
any other way of obtaining them.