Skip to content

mlx: add build-mlx.yml for riscv64 wheels - #1874

Merged
luhenry merged 3 commits into
mainfrom
mlx
Sep 14, 2026
Merged

luhenry merged 3 commits into
mainfrom
mlx

Conversation

@luhenry

@luhenry luhenry commented Sep 13, 2026

Copy link
Copy Markdown
Member

Apple's array/ML framework; this builds its CPU-only backend (Metal is macOS-only and already skipped by upstream's own CMakeLists on Linux). Upstream publishes no riscv64 wheel for either package it releases here.

Mirrors upstream's release.yml build_frontend/build_backend/test_wheel jobs, narrowed to Linux cpu: mlx (per-interpreter nanobind bindings) and mlx-cpu (the compiled libmlx.so) both ship, since one is useless without the other.

Differs from upstream

  • Adds -DCMAKE_INSTALL_LIBDIR=lib - Rocky's lib64 default otherwise makes setup.py's backend packaging step drop the compiled libmlx.so entirely.
  • Drops -DCMAKE_COMPILE_WARNING_AS_ERROR=ON - the image's newer libstdc++ deprecates std::atomic_exchange/atomic_load on shared_ptr, which upstream's own older-libstdc++ runners never see.

Testing

  • same as upstream (python/tests/run.py); torch/ml_dtypes stay import-guarded and optional like upstream

License: Wheel bundles libopenblas (BSD) and libgfortran (GPL-3.0 with the GCC runtime exception); upstream ships no licence text for either, so the build adds openblas's and a gpl_sources job publishes gcc's.

Built on cp312 (aarch64 rehearsal); 785 passed, 88 skipped, 0 failed.

Mirrors upstream's frontend/backend release split (mlx + mlx-cpu) and its
own test-wheel action on the riscv64 manylinux image. Forces
CMAKE_INSTALL_LIBDIR=lib since Rocky's lib64 default otherwise makes
setup.py's backend packaging step drop the compiled libmlx.so.
luhenry added a commit that referenced this pull request Sep 13, 2026
setup.py's get_version() shells out to 'git rev-parse --short HEAD'; the
bind-mounted checkout is owned by a different uid than the container's
root, so git refuses it as dubious ownership without this.
test_compile_release_on_another_thread expects gc.collect() on one thread
to synchronously finalize a compiled function's thread_local cache entry
observed from another; cp314t's true parallelism does not guarantee that
ordering the way GIL-serialized builds do (reproduced deterministically
twice, see ml-explore/mlx#4377 for the thread_local+weak_ptr design this
stresses).
luhenry added a commit that referenced this pull request Sep 13, 2026
@luhenry
luhenry merged commit 7e5e686 into main Sep 14, 2026
16 checks passed
@luhenry
luhenry deleted the mlx branch September 14, 2026 09:28
@luhenry luhenry mentioned this pull request Sep 14, 2026
@luhenry luhenry linked an issue Sep 14, 2026 that may be closed by this pull request
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

mlx riscv64 support

1 participant