v0.5.9

Unofficial community build. Not affiliated with Modular or Qualcomm.

The release where the native Windows build of //Support/... stops being a list of problems and becomes one problem. Two changes land, they close #272 and #292, and the top level count goes from 480 of 503 to 504 of 505. The one that is left is a Nanobind extension, which Linux does not build either. There is still no Mojo compiler for Windows and nothing in this release produces one, but the support library that a compiler would be built on now compiles and links on the machine that would build it.

Pinned to upstream modular/v25.7.0-29742-g9aba62be84, commit 9aba62be844d73b574a4283a1a8ce760f9843134.

Download mojo-windows-runtime-0.5.9-x86_64.zip, unpack it, run bin\hello.exe. Nothing to install first. Windows 10 version 1809 or later, x64.

What changed

#293 is the source half of #272, which the last three releases kept approaching from the build configuration side and kept finding another layer under. Eleven of them were about the C library. Nine tests and two benchmarks call setenv, which is POSIX rather than C, and the MSVC runtime implements C. It has _putenv_s instead, same idea and a different signature. The choice was an #ifdef at every call site or one small header that supplies the POSIX spelling in terms of what the platform has, and the header won, because the call sites are otherwise identical and there are a lot of them.

The rest of #293 is smaller and the same shape. Six log tests built a temporary file path by writing /tmp into a string, and now ask LLVM where the temporary directory is. Two benchmarks wrote to /dev/null, which on Windows is spelled NUL and is not in the filesystem. One test expected testing::KilledBySignal, which a Windows gtest does not have because Windows has no signals to be killed by, so it matches on the exit code the C runtime produces instead. Two files passed a std::filesystem::path where a narrow string was wanted, which works everywhere that a path's native character type is char. And six #error "Test requires modification for Windows" markers, left by somebody who meant them, are gone.

#295 is the link half, and both failures in it are the same mistake: a symbol told to travel through a DLL when it was never going to.

Seven targets got mlir::detail::FallbackTypeIDResolver::registerImplicitTypeID twice, once from MLIR's own object file and once from the MSupportGlobals import library. The build forces that function into the shared library and exports it, which on Linux and macOS is not about having a copy there. It is about every other loaded module giving up its own copy and using that one, and it works because ELF and Mach-O resolve a global symbol to a single definition across the whole process. Windows has no such rule. A module reaches a symbol in a DLL only if it was compiled to look for it there, and the MLIR header declares this function plainly, so nothing ever is. Both flags that spell the trick on Windows worked exactly as documented and produced a DLL exporting a function that no caller could be pointed at, plus a duplicate symbol in every executable linking both MLIR and that DLL.

The eighth was M::Context::~Context, wanted as an import and found sitting in an object file. The header marked it for export and the target carried the define to match, but that target is a static library, so there was no DLL for the marking to be about, and every consumer that links the object directly was being sent to look elsewhere. Deleting the marking outright was not an option, because the build compiles with -fvisibility=hidden and that would have changed what Linux exports. So there is a new macro for the static library case which says default visibility on ELF and Mach-O and says nothing at all on Windows.

What the second one costs

Emptying that select is not free. MLIR type identity no longer survives a module boundary on Windows: each module keeps its own registry, and a type registered in one is not the same type in another. That is a real gap, it is written up as #294 with three cheaper workarounds listed, and the actual fix is on the other side of it, which is one shared MLIR rather than a static MLIR in every module and a trick to make the copies agree.

Nothing shipped here depends on that, and eight link failures traded for a gap that is written down is the right way round. But it is a gap and not a fix.

What is different in the archive

Unlike the last two releases, the runtime is not byte for byte what it was. MSupportGlobals.dll and its import library changed, and that is the #295 change arriving: the exported registerImplicitTypeID is in the v0.5.8 DLL and is not in this one, which was checked rather than assumed.

hello.exe, AsyncRTRuntimeGlobals.dll and KGENCompilerRTShared.dll also differ, and there the honest answer is that no interface of theirs changed, because their import libraries are byte for byte identical to v0.5.8. What moved is almost certainly the embedded debug signature, which changes whenever something they are built on top of is relinked. example/hello.mojo, upstream.lock, LICENSE and NOTICE are unchanged, and README.txt differs only in the version number.

Test results

Every suite is exactly where it was in v0.5.8.

Windows tier 0 is 232 of 238, with 232 passing, one target that does not build and five skipped. Windows tier 1 is 75 of 78, with 75 passing and three skipped. The Win64 ABI conformance suite is 13 of 13 passing. Linux tier 0 is 236 of 238, with 236 passing and two that do not build. Linux tier 1 is 76 of 78, with 76 passing and two skipped. Linux //Support/... is 324 of 326, with one target that does not build and one that fails, both of them Nanobind and both of them failing on the previous release too.

The target that does not build on either platform is #230, an AMDGPU codegen test with nothing to do with Windows. The second Linux one is an nvptx64 test that only Linux gets far enough to attempt.

The kgen and mojo-tool lit suites were not re-run for this release. They were 321 of 321 in v0.5.8 and nothing here touches them, but that is a reason to expect a number rather than a number.

Manual acceptance

The smoke test was done properly: this exact archive was unpacked on a Windows machine into a clean directory and bin\hello.exe run from where it landed, printing Hello from Mojo and built for Windows: True and exiting zero.

The rest of the v0.5.6 record stands and is in docs/acceptance.md. Items 3, 4, 6, 7 and 8 passed there, covering non ASCII paths, paths with spaces, crash output for an access violation and a stack overflow, an import table with nothing unexpected in it, and a Defender scan that left everything alone. Those were checked against a runtime that has since been relinked, which is worth knowing when reading them. Item 1 is still not applicable because there is no mojo.exe to start a REPL with. Items 2 and 5 still need a person at a real console, one to judge how the colours read and one to press Ctrl-C, and nobody has done either yet.

What still does not work

There is still no Mojo compiler for Windows. Everything here is cross compiled from Linux and the archive is a runtime and one example program, not a toolchain.

There is no COFF JIT, so no REPL and no mojo run, which is #31. The prebuilt MAX wheel has no Windows build, so a large block of aliases has nothing to resolve to, which is #115. MLIR type identity does not cross a module boundary on Windows, which is #294 and is new in this release. And the native build, now that it gets through //Support, has the rest of the tree in front of it.

Files

The overlay archives are built by CI from the tag and carry a provenance attestation. The Windows archives are cross compiled from Linux by hand and carry checksums only, because CI cannot build them and attesting them there would sign a claim that is false. docs/releasing.md explains that at more length.

Verify what you downloaded before using it:

sha256sum -c SHA256SUMS
sha256sum -c SHA256SUMS-windows
gh attestation verify <file> --repo tamnd/mojo.windows

The Windows binaries are unsigned, so Windows will warn about them the first time you run one from Explorer. That is expected. docs/downloading.md says what the warning looks like, what decides whether you see it at all, and how to get past it.