Skip to content

Add Windows/mingw32 support, native and cross#84

Merged
arnetheduck merged 1 commit into
masterfrom
win
Jan 8, 2026
Merged

Add Windows/mingw32 support, native and cross#84
arnetheduck merged 1 commit into
masterfrom
win

Conversation

@arnetheduck

Copy link
Copy Markdown
Owner

This one turned out to be a lot easier than anticipated!

As it happens, the existing code is already perfectly well capable of compiling things on windows and all that's needed is a bit of patching and plumbing on the linking side and voila, it just works.

The setup, as tested by CI, uses mingw (plausibly it could be extended to msvc as well, but why?) to provide the compiler runtime and the Windows support libraries needed to link, but otherwise just works out of the box, and the binaries produced are fully stand-alone (apart from the usual Windows DLL dependencies).

  • Improve target triple handling - the "just works" thing might actually carry over to all platforms llvm supports, meaning that flags like --cpu:arm64 will do the right thing - tests needed to verify this
  • Add support for cross-compiling to windows using llvm-mingw as the recommended windows environment
  • In theory, it should be easy to support an msvc build environment as well using something like xwin to fetch the windows SDK - tests and documentation needed

The way compilation is set up, nlvm will compile the Nim code as usual and then invoke the built-in lld linker to link an executable.

To link, lld needs either .dll or .lib files for each shared library used by the application - the C and windows system libraries in particular (msvcrt, kernel32 etc). Linking minics what clang would do.

We also need a compiler runtime library - this is taken from the existing C compiler setup, meaning libgcc for gcc and compiler-rt/libunwind for clang.

When cross-compiling, the same thing applies but we'll now also use clang to find the support libraries for the target environment, so clang needs to be compiled in such a way to find the installed mingw32-w64 environment - the easiest thing to do is to just download llvm-mingw and put it first in the PATH.

This one turned out to be a lot easier than anticipated!

As it happens, the existing code is already perfectly well capable of
compiling things on windows and all that's needed is a bit of patching
and plumbing on the linking side and voila, it just works.

The setup, as tested by CI, uses mingw (plausibly it could be extended
to msvc as well, but why?) to provide the compiler runtime and the
Windows support libraries needed to link, but otherwise just works out
of the box, and the binaries produced are fully stand-alone (apart from
the usual Windows DLL dependencies).

* Improve target triple handling - the "just works" thing might actually
carry over to all platforms llvm supports, meaning that flags like
`--cpu:arm64` will do the right thing - tests needed to verify this
* Add support for cross-compiling to windows using `llvm-mingw` as the
recommended windows environment
* In theory, it should be easy to support an msvc build environment as
well using something like [xwin](https://github.com/Jake-Shadle/xwin) to
fetch the windows SDK - tests and documentation needed

The way compilation is set up, `nlvm` will compile the Nim code as usual
and then invoke the built-in `lld` linker to link an executable.

To link, `lld` needs either `.dll` or `.lib` files for each shared
library used by the application - the C and windows system libraries in
particular (`msvcrt`, `kernel32` etc). Linking minics what `clang` would
do.

We also need a compiler runtime library - this is taken from the
existing C compiler setup, meaning `libgcc` for `gcc` and
`compiler-rt`/`libunwind` for `clang`.

When cross-compiling, the same thing applies but we'll now also use
`clang` to find the support libraries for the target environment, so
clang needs to be compiled in such a way to find the installed
mingw32-w64 environment - the easiest thing to do is to just download
llvm-mingw and put it first in the PATH.
@arnetheduck arnetheduck merged commit da658c6 into master Jan 8, 2026
6 checks passed
@arnetheduck arnetheduck deleted the win branch January 8, 2026 07:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant