v0.5.7

Unofficial community build. Not affiliated with Modular or Qualcomm.

A patch release, and it closes the oldest open item left over from #134. A shared library built for Windows can now reach outside itself: the link line knows about library search paths and import libraries, so a module that calls into the C runtime or back into the Mojo runtime links instead of failing on symbols it was never going to be able to resolve on its own.

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

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

What changed

All of it is #280, in three parts.

The link that turns an object into a Windows shared library now takes arguments from configuration. mojo-max.shared_object_libs is a comma separated list that goes on the lld-link line untouched, which is where an install puts the /libpath: for its C runtime and the /defaultlib: for the libraries in it. ELF and Mach-O do not need this, because either format is happy to leave a symbol undefined and let the loader find it at load time. COFF is not: a DLL has to resolve everything it references at link time, and it reaches the C runtime through an import library or not at all. Nothing in the compiler knows where an install put one, so somebody has to say, and until now there was no way to.

The Mojo runtime's own import library is the exception, because the compiler can find that one itself. It sits in the install as lib/KGENCompilerRTShared.lib, right next to the DLL it describes, and the compiler already knows where the rest of its files are. It goes on the line automatically when the target is COFF and the file is really there, and the second half of that matters more than it looks: most of these builds are a Linux host cross compiling for Windows, and naming a file that does not exist would turn every link that never wanted a runtime into an error about a missing library.

Then a test that proves the whole thing rather than proving an argument arrived. It links a module that calls puts and does not define it, and checks the symbol comes out of the result as an import from api-ms-win-crt-stdio-l1-1-0.dll. That is a link that failed before this release and succeeds now. It needs a real Windows CRT and SDK on the machine, which cannot be redistributed, so it is gated on a new windows-sysroot lit feature and is reported as unsupported anywhere MOJO_WINDOWS_SYSROOT does not point at a real one. docs/building.md has the command that runs it.

Worth being clear that this is the kgen -emit=shared-lib path only. mojo build --emit shared-lib goes through the linker driver and gets its libraries from there, so it was never affected.

None of this is in the archive below. The archive is a runtime and an example rather than a toolchain, and nothing that goes into it changed in this release. It matters for what comes next.

Test results

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

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 lit suite is 220 of 220 and mojo-tool is 101 of 101. kgen was 217 in v0.5.6 and the three new tests are the three parts above. The last of them was also run with a sysroot present, to check it passes rather than only that it is skipped, and run with a sysroot path that does not exist, to check it is skipped rather than failing.

Manual acceptance

Not re-run, and that is a deliberate call rather than an omission. Nothing that goes into the archive changed between v0.5.6 and this tag: the three pull requests touch the compiler's object emission, its configuration, the lit harness and the docs, and none of them touch the runtime, the example or the packaging.

That is checked rather than asserted. Every file inside this archive has the same CRC as the file of the same name inside the v0.5.6 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. The zips themselves have different checksums because a zip records when it was made.

What was done is the smoke test: this archive was unpacked on a Windows machine and bin\hello.exe was run from where it landed, which prints and exits zero. That is the check that catches a packaging mistake, and a packaging mistake is the only kind of thing that could have gone wrong between the two tags.

The rest of the v0.5.6 record stands, and it is in docs/acceptance.md. Items 3, 4, 6, 7 and 8 passed there, covering non ASCII paths, paths with spaces, crash output for both an access violation and a stack overflow, an import table of KGENCompilerRTShared.dll and KERNEL32.dll and nothing else, 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.

A shared library can link against the C runtime now, and an install still has to be told where its C runtime is, because the compiler has no way to find one. There is no COFF JIT, so there is 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. The support tests and benchmarks do not compile when the machine driving the build is Windows, which is #272 and is the largest thing left in this milestone.

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.