mojo: init at unstable-2026-08-21

[hnkNkm]

Summary

• Add a source-built mojo package (//KGEN:mojo via buildBazelPackage) after Modular open-sourced the compiler (Apache-2.0 + LLVM exceptions).
• This is not a reopen of the binary-wheel PR mojo: init at 1.0.0b2.dev2026052421 #523845. The old package request is Package request: mojo #257274.

Changes

• pkgs/by-name/mo/mojo/package.nix
  • Builds the compiler and stdlib with --config=build-mojo --compilation_mode=opt.
  • C/C++ toolchain is nixpkgs LLVM 22 and glibc (not Modular's S3 clang / Ubuntu jammy sysroot). llvm-ifs is nixpkgs LLVM as well.
  • Host Bazel is nixpkgs bazel_9. Host Python is nixpkgs CPython (local_runtime plus install_only-style tarballs for python.toolchain()).
  • Public mojo is a normal makeWrapper (no buildFHSEnv). mojo-full uses the Nix glibc PT_INTERP.
  • passthru.tests.hello and passthru.tests.interpreter (Nix glibc PT_INTERP, stripped, no llvm-ifs runfiles).
  • Follow-on unwrapped derivation strips DWARF, hardlinks duplicate Bazel runfiles, and sets disallowedReferences on the fat compile output.
• pkgs/by-name/mo/mojo/{clang-linux,llvm-ifs-nix,sysroot-nix,python-standalone-nix}.nix
  • Layout adapters so Modular's Bazel repos resolve against nixpkgs.
• maintainers/maintainer-list.nix
  • Add hnknkm.

Testing

Verified on x86_64-linux (staging flake using this derivation):

nix build .#checks.x86_64-linux.hello
nix build .#checks.x86_64-linux.interpreter

• mojo --version → Mojo 1.1.0.dev0 (deadbeef)

• hello.mojo prints Hello, Mojo

• mojo-full PT_INTERP is Nix glibc (/nix/store/...-glibc-.../lib/ld-linux-x86-64.so.2), not /lib64

• mojo-full is stripped; link-time llvm-ifs is not in runfiles

• Compile of //KGEN:mojo was ~3h38m (11189 actions) on x86_64-linux. The public unwrapped output is a follow-on derivation that strips DWARF and hardlinks duplicate Bazel runfiles (about 631 MiB on disk, ~1.0 GiB closure). The compile derivation uses requiredSystemFeatures = [ "big-parallel" ]. ofBorg may not finish a full compile.

Notes

• x86_64-linux only. GPU/MAX/CUDA is out of scope.
• Release tag max/v26.5.0 predates compiler OSS, so this pins post-OSS commit 577b6b839efa11d750cdf264f1094954cc7d5b25 as unstable-2026-08-21.
• meta.sourceProvenance includes binaryNativeCode because the Bazel vendor tarball still contains host tools used during analysis (crashpad, buildifier, Go/Node/uv). The compiler C/C++ toolchain itself is nixpkgs LLVM/glibc; GPU blobs such as nvshmem are not vendored for //KGEN:mojo.
• clang 22 needs ulimit -s unlimited on the driver wrappers and -O0 for NativePDB (SIGSEGV at -O2).

Things done

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • aarch64-darwin
• Tested, as applicable:
  • NixOS tests in nixos/tests.
  • Package tests at passthru.tests.
  • Tests in lib/tests or pkgs/test for functions and "core" functionality.
• Ran nixpkgs-review on this PR.
• Tested basic functionality of all binary files, usually in ./result/bin/.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.
• Follows the automation/AI policy.

Assisted by Cursor Grok 4.6 when drafting the derivation and this summary. I built the package and ran the tests above.

[hnkNkm]

@samuela I looked into the question you raised on #559250 — whether GPU/MAX could be added to this source build.

It cannot, at least not from the public Modular tree. The MAX C++ runtime (MLRT / DeviceContext) is not published, and the public Bazel API forces accelerator support off. On the compiler this PR produces, --print-supported-accelerators is empty, --target-accelerator nvidia:sm_75 --emit asm does not emit PTX, and from max.gpu.host import DeviceContext fails.

So I think #559250 is the better first pkgs.mojo: it is the 1.0.0 release, covers both Linux architectures, and actually ships CUDA/MAX. I am fine with this PR not taking the mojo attribute. Happy to leave it open as a free CPU-only compiler if that is useful, or close it if reviewers would rather have a single package.

[samuela]

It cannot, at least not from the public Modular tree. The MAX C++ runtime (MLRT / DeviceContext) is not published, and the public Bazel API forces accelerator support off. On the compiler this PR produces, --print-supported-accelerators is empty, --target-accelerator nvidia:sm_75 --emit asm does not emit PTX, and from max.gpu.host import DeviceContext fails.

Ah, that's a bummer esp considering the press around the open source release. I was not aware of this.

So I think #559250 is the better first pkgs.mojo: it is the 1.0.0 release, covers both Linux architectures, and actually ships CUDA/MAX. I am fine with this PR not taking the mojo attribute. Happy to leave it open as a free CPU-only compiler if that is useful, or close it if reviewers would rather have a single package.

Another option would be to do a mojo and mojo-bin split. We previously did this (maybe still do?) for jaxlib and tensorflow and it worked smoothly and encouraged the source builds to eventually reach parity with the binary builds. Would you be interested in such a setup?

[hnkNkm]

@samuela Yes, a mojo / mojo-bin split works for me.

I would keep this PR as the source-built mojo: free, CPU-only, x86_64-linux. #559250 would be the better mojo-bin: the 1.0.0 wheels, both Linux architectures, and CUDA/MAX.

One caveat on the jaxlib/tensorflow analogy: source will not grow GPU/MAX until Modular publishes the closed pieces (MLRT / device codegen). That is an upstream availability gap, not something this derivation can close by packaging work. Until then the two packages would stay complementary rather than on a path to parity.

Happy to keep maintaining the source package on that basis.

[samuela]

sg, enabled github actions on this pr and renamed derivation to mojo-bin in #559250