v0.5.8

Unofficial community build. Not affiliated with Modular or Qualcomm.

A patch release about a machine that has never been able to build this project: a Windows one. Four changes land, three of them are the same story told three times, and between them a native Windows build of //Support/... goes from 378 of 503 top-level targets to 480. That is not a working compiler yet and nothing in the archive below changed, but it is the first release where the native build stops being a wall and starts being a list.

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

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

What changed

#272 says the support tests and benchmarks do not compile when the machine driving the build is Windows. Work on it started at the cheapest looking end, the link flags, and each target behind those flags turned out to have a second thing wrong underneath it. So three releases worth of finding out, in one release.

#287 is protobuf. Its link options have an arm for Windows carrying -ldbghelp, -lpthread and -lm, written for MinGW where all three name real libraries. Against an MSVC target the last two become pthread.lib and m.lib, and neither exists, because the C runtime already provides both. Twenty four missing library errors went to none and the top level count did not move at all, which is how the next two got found.

#290 is abseil. It marks its per thread semaphore functions with a weak attribute, which it turns on for Windows whenever clang is new enough, and that is right for compiling and wrong for linking. Bazel puts a library's object files inside a start-lib group, which makes each one lazy, and lld-link will not pull in a lazy object to satisfy a reference that is only weak. So the definitions sat on the link line unread while mutex.obj went looking for them. Turning the attribute off on Windows is what abseil already does for MinGW. Twelve undefined symbols went to none and the count moved to 388.

#291 is the interesting one. Three DLL links failed with nothing but The command line is too long., which is not the linker talking, it is cmd.exe declining to start linker-driver.bat with about forty thousand characters after it. Bazel can write those arguments into a file and pass @file instead, and this toolchain has asked it to since the Windows host work started, but rules_cc decides the shared library case by asking whether a feature called targets_windows is on, and this toolchain does not turn that on. The comment above the check says the restriction is a Unix one and probably unintended, and what it is really protecting is a shell script that reads its arguments positionally and that we never run. So the check now asks about the tool rather than about the platform. That one change moves the count from 388 to 480, because the DLL it was blocking is what most of //Support is built on.

#286 is unrelated and much smaller. Python 3.10 on Windows cannot work out where its own standard library is unless something tells it, so an embedded interpreter now gets a PYTHONHOME pointing at the install it was found in. Every version after 3.10 works this out for itself.

Being straight about the number

480 of 503 is up ninety two, and the error count went up too, from 21 lines to 25. That is not a contradiction, it is what happens when a blockage clears: ninety two targets that had never been attempted got attempted, and some of them failed.

Eleven of the 25 are the source level failures #272 was always about, setenv and unsetenv and mkstemp with no MSVC C runtime equivalent, testing::KilledBySignal missing from a Windows gtest, and an explicit #error "Test requires modification for Windows" that somebody left in years ago and meant. Six are a duplicate mlir::detail::FallbackTypeIDResolver::registerImplicitTypeID, which is a known MLIR problem on Windows. Two are an undefined M::Context::~Context marked dllimport, which is new and has not been looked at yet. The rest are Nanobind and mypy failures downstream of the ones above.

Test results

Every cross compiled suite is exactly where it was in v0.5.7, and for #291 that is provable rather than observed: the check it patches returns early unless the toolchain says it supports parameter files, which this one only says on a Windows host.

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. The target that does not build on either platform is #230, an AMDGPU codegen test that has nothing to do with Windows.

The kgen and mojo-tool lit suites are 321 of 321, unchanged from v0.5.7.

Manual acceptance

Not re-run in full, for the same reason as last time and checked the same way. Every file inside this archive has the same CRC as the file of the same name inside the v0.5.7 archive: all three DLLs, all three import libraries, hello.exe, hello.mojo, upstream.lock, LICENSE and NOTICE. The only entry that differs is README.txt, which has the version number in it. That is what you would expect from four changes to how the build works on a Windows host and one to how an embedded interpreter finds its standard library, none of which are in a cross compiled runtime.

The smoke test was done: this archive was unpacked on a Windows machine 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. 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 contains a runtime and one example program rather than a toolchain. The native build is closer than it was this morning and still does not produce one.

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. And #272 is still open, now down to the parts that need actual source changes rather than build configuration.

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.