feat: vendor mlx-c at pinned commit SHA for stable builds #1

Open
opened 2026-02-24 13:48:37 +00:00 by Virgil · 0 comments
Member

Problem

brew upgrade can silently change the Metal/MLX allocator behaviour, breaking memory management that was previously working. The CGO build links against whatever mlx-c brew has installed, making builds non-reproducible.

Proposal

Vendor mlx-c headers + static library at a known-good commit SHA.

Options considered

  1. Vendor headers + static lib (recommended) — clone at pinned SHA, build once, check in .a + headers. CGO links against vendored copy.
  2. Git submodule at pinned SHA — less repo bloat but adds build step.
  3. Pre-built release artifacts — clean but more CI infra.

What to vendor

  • mlx-c headers (few hundred KB)
  • Pre-built libmlx.a for darwin/arm64
  • Record the commit SHA + MLX version in a VENDORED file

Why

  • Reproducible builds across machines
  • Required for distribution (App Store, standalone binary)
  • Isolates us from upstream API changes (e.g. mx.metal.* deprecation)
  • Known-good memory management behaviour

Priority

Not urgent — needed before any distribution/release. Track alongside LEM Lab packaging.

## Problem `brew upgrade` can silently change the Metal/MLX allocator behaviour, breaking memory management that was previously working. The CGO build links against whatever mlx-c brew has installed, making builds non-reproducible. ## Proposal Vendor mlx-c headers + static library at a known-good commit SHA. ### Options considered 1. **Vendor headers + static lib** (recommended) — clone at pinned SHA, build once, check in `.a` + headers. CGO links against vendored copy. 2. **Git submodule at pinned SHA** — less repo bloat but adds build step. 3. **Pre-built release artifacts** — clean but more CI infra. ### What to vendor - `mlx-c` headers (few hundred KB) - Pre-built `libmlx.a` for `darwin/arm64` - Record the commit SHA + MLX version in a `VENDORED` file ### Why - Reproducible builds across machines - Required for distribution (App Store, standalone binary) - Isolates us from upstream API changes (e.g. `mx.metal.*` deprecation) - Known-good memory management behaviour ## Priority Not urgent — needed before any distribution/release. Track alongside LEM Lab packaging.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: core/go-mlx#1
No description provided.