v0.5.3

Unofficial community build. Not affiliated with Modular or Qualcomm.

A patch release. Nothing about the packaged runtime changed, the binaries here are the same programs built from the same pin as v0.5.0. What changed is that a Windows host now gets past analysis and runs a real compile action, with clang actually executing on Windows. That is not a compiler yet, but it is the difference between a machine that can plan the build and a machine that has started doing it. M6 work, native hosting.

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

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

What changed

All five changes here came out of the same exercise, which was to sit at a Windows machine, ask Bazel for a real target, and fix whatever it hit. Each one was invisible until the one before it was fixed.

The pip lock file now has a Windows environment. The rc turns on the mypy aspect for every build, so every target in the tree depends on mypy resolving, and the lock file declared darwin and linux and nothing else. Analysis stopped on a Windows host before it had looked at a single source file. That is #252.

The TestRunner strategy chain no longer names a strategy that does not exist on Windows. It named sandboxed, and there is no sandbox on Windows, and Bazel validates every name in a chain up front rather than quietly skipping the ones that are not registered. So the invocation failed after analysis had already succeeded, which is a confusing place to be told about a test strategy when you asked for a build. That is #256.

The crosstool module map is built without a shell. builtin_module_map was shelling out to find, once per include directory, to list the files under it. There is no shell on Windows for Bazel to run that in, and on a machine with WSL installed it finds bash.exe in System32 and runs the script inside the Linux distribution, where none of the Windows execroot paths exist. The list find was producing is one Bazel already had, since the same depset was being handed to the action as its inputs, so the rule builds the file in Starlark now and there is no action left to fail. Checked byte for byte against the old output on Linux, 3076 lines either way. That is #259.

Path mapping is set per host instead of unconditionally. --experimental_output_paths=strip stops a configuration transition from rebuilding C++ that did not change, and Bazel only implements it for a spawn that runs sandboxed or remotely. With no sandbox on Windows, every C++ compile in the tree refused to run and blamed the strategy flags for being too strict, which was not the problem: the two strategies a Windows host has are the only two it can have and neither can do path mapping, so the requirement could never be met. It is now on the linux and macos arms. The cost is that a Windows host rebuilds C++ across a configuration change that would have been free on the other two, which is the right trade while the alternative is not building. That is #260.

The three cc toolchain drivers can be started. They are Python scripts, Windows has no shebang, and CreateProcess refuses a .py whatever the file association says, so the first compile action failed to launch with error 193 before anything had been compiled. Each driver now gets a small .bat generated beside it on a Windows host, which Bazel does know how to start through cmd.exe, and the interpreter is written into it as an absolute path found by a new repository rule. It has to be absolute: the rc sets --incompatible_strict_action_env, which on Windows gives an action a PATH of system32, windows, wbem and powershell, and no Python installer puts anything in any of them. That is #253.

One more, found while cutting this release rather than while building. package-windows.sh walked the Bazel output tree for the import library beside each DLL, and the rc only materialises the outputs the requested target names, so it was reading files left over from an earlier build rather than files this build produced. On a machine where they were not lying around it stopped, correctly, with an error. Debug information was the same shape with a worse ending: a missing .pdb was treated as debug information not being wanted, so the -pdb.zip was quietly not made. Both are errors now and this build downloads what it reads. That is #266.

Test results

Every suite is unchanged, which is the point of a patch release.

Windows tier 0 is 232 passing, one target that does not build and five skipped. Windows tier 1 is 75 passing and three skipped. The Win64 ABI conformance suite is 14 of 14. Linux tier 0 is 236 passing with two that do not build, Linux tier 1 is 76 passing and two skipped. The build failures are #230, an AMDGPU codegen test, and an overflow test, neither of them Windows specific. Two Windows tier 0 tests failed on the first run with cp: ... Cannot allocate memory while staging to /mnt/c, which is the WSL to Windows filesystem boundary running out of room at eight jobs rather than anything about the test, and both pass on a rerun.

The manual acceptance checklist is unchanged from v0.5.2 and every result is in docs/acceptance.md. Nothing in this release touches the packaged archive, so nothing in that list could have moved.

What still does not work

There is still no mojo.exe. A compile action that starts is not a compiler.

Two things are in the way now and both were found by getting this far. Command lines on Windows are too long: cmd.exe caps at 8191 characters, CreateProcess at 32767, and a few hundred compile actions and seven link actions in the compiler's graph are past those limits, so the Windows toolchain needs param files. That is #263. Underneath it, the llvm-project repository reaches its sources through relative symlinks that do not resolve through the execroot junction on Windows, so an LLVM compile is handed a source path that is not there. That is #264.

A stack overflow still prints nothing, which is #239, and it still arrives as an access violation rather than as STATUS_STACK_OVERFLOW, which is #238. Every other fault prints a proper symbolised trace.

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.