github-starred/ollama
2
0
Fork 0
mirror of https://github.com/ollama/ollama.git synced 2026-05-07 00:22:43 -05:00
Code Issues 14.5k Packages Projects Releases 120 Wiki Activity

[PR #14201] x/imagegen/mlx: fall back to system mlx-c headers in wrapper generation #76858

New Issue
Open
opened 2026-05-05 09:33:41 -05:00 by GiteaMirror · 0 comments
GiteaMirror commented 2026-05-05 09:33:41 -05:00
Owner
Copy Link

📋 Pull Request Information

Original PR: https://github.com/ollama/ollama/pull/14201
Author: @mariusdkm
Created: 2/11/2026
Status: 🔄 Open

Base: main ← Head: fix/mlx-system-headers

📝 Commits (1)

  • c051122 x/imagegen/mlx: fall back to system mlx-c headers in wrapper generation

📊 Changes

1 file changed (+34 additions, -7 deletions)

View changed files

📝 x/imagegen/mlx/generate_wrappers.go (+34 -7)

📄 Description

Problem

Distribution builds (like Homebrew) that install ollama from source fail at runtime with:

MLX: Failed to load symbol: mlx_metal_device_info

Root cause: generate_wrappers.go only looks for mlx-c headers at the cmake FetchContent path (build/_deps/mlx-c-src/mlx/c). Distribution builds don't run cmake — they have mlx-c installed as a system library. When go generate -tags=mlx runs, it can't find headers, so stale committed wrappers ship. These reference symbols removed in mlx-c v0.5.0 (mlx_metal_device_info was replaced by mlx_device_info_new).

Refs: #14187, Homebrew/homebrew-core#266704

Solution

Two changes to generate_wrappers.go:

  1. Header discovery fallback — when the cmake path doesn't exist, check common system install locations (/opt/homebrew/include/mlx/c, /usr/local/include/mlx/c, /opt/local/include/mlx/c). This lets distribution builds regenerate wrappers against their installed mlx-c version without requiring cmake.

  2. Resolve symlinks in findHeaders — Homebrew installs headers as symlinks into the Cellar. filepath.WalkDir uses Lstat on the root entry, which sees a symlink as isDir=false and skips traversal entirely. Adding filepath.EvalSymlinks before walking fixes this.

No changes to doc.go, cmake builds, or runtime behavior. The cmake FetchContent path is still tried first — the fallback only triggers when it doesn't exist.

Distribution impact

Homebrew (and similar) formulas can now run:

system "go", "generate", "-tags=mlx", "./..."
system "go", "build", "-tags=mlx", *std_go_args(ldflags:)

This regenerates wrappers against the installed mlx-c version, preventing symbol mismatches regardless of what version the committed wrappers target.

Testing

Tested on Apple Silicon (M3 Pro, macOS 15) with mlx-c 0.5.0 installed via Homebrew:

  • cmake build path (backward compat): cmake path found first, fallback not triggered
  • System mlx-c path: cmake path absent -> falls back to /opt/homebrew/include/mlx/c -> generates 586 functions from 28 headers
  • Symlink resolution: findHeaders now correctly traverses Homebrew's symlinked directories
  • No headers anywhere: clear error message with both cmake and brew install instructions

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/ollama/ollama/pull/14201 **Author:** [@mariusdkm](https://github.com/mariusdkm) **Created:** 2/11/2026 **Status:** 🔄 Open **Base:** `main` ← **Head:** `fix/mlx-system-headers` --- ### 📝 Commits (1) - [`c051122`](https://github.com/ollama/ollama/commit/c051122297824c223454b82f4af3afe94379e6dd) x/imagegen/mlx: fall back to system mlx-c headers in wrapper generation ### 📊 Changes **1 file changed** (+34 additions, -7 deletions) <details> <summary>View changed files</summary> 📝 `x/imagegen/mlx/generate_wrappers.go` (+34 -7) </details> ### 📄 Description ## Problem Distribution builds (like Homebrew) that install ollama from source fail at runtime with: ``` MLX: Failed to load symbol: mlx_metal_device_info ``` **Root cause:** `generate_wrappers.go` only looks for mlx-c headers at the cmake FetchContent path (`build/_deps/mlx-c-src/mlx/c`). Distribution builds don't run cmake — they have mlx-c installed as a system library. When `go generate -tags=mlx` runs, it can't find headers, so stale committed wrappers ship. These reference symbols removed in mlx-c v0.5.0 (`mlx_metal_device_info` was replaced by `mlx_device_info_new`). Refs: #14187, Homebrew/homebrew-core#266704 ## Solution Two changes to `generate_wrappers.go`: 1. **Header discovery fallback** — when the cmake path doesn't exist, check common system install locations (`/opt/homebrew/include/mlx/c`, `/usr/local/include/mlx/c`, `/opt/local/include/mlx/c`). This lets distribution builds regenerate wrappers against their installed mlx-c version without requiring cmake. 2. **Resolve symlinks in `findHeaders`** — Homebrew installs headers as symlinks into the Cellar. `filepath.WalkDir` uses `Lstat` on the root entry, which sees a symlink as `isDir=false` and skips traversal entirely. Adding `filepath.EvalSymlinks` before walking fixes this. No changes to `doc.go`, cmake builds, or runtime behavior. The cmake FetchContent path is still tried first — the fallback only triggers when it doesn't exist. ## Distribution impact Homebrew (and similar) formulas can now run: ```ruby system "go", "generate", "-tags=mlx", "./..." system "go", "build", "-tags=mlx", *std_go_args(ldflags:) ``` This regenerates wrappers against the installed mlx-c version, preventing symbol mismatches regardless of what version the committed wrappers target. ## Testing Tested on Apple Silicon (M3 Pro, macOS 15) with mlx-c 0.5.0 installed via Homebrew: - cmake build path (backward compat): cmake path found first, fallback not triggered - System mlx-c path: cmake path absent -> falls back to `/opt/homebrew/include/mlx/c` -> generates 586 functions from 28 headers - Symlink resolution: `findHeaders` now correctly traverses Homebrew's symlinked directories - No headers anywhere: clear error message with both cmake and brew install instructions --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
GiteaMirror added the pull-request label 2026-05-05 09:33:41 -05:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
amd
api
app
bug
build
cli
cloud
compatibility
context-length
create
docker
documentation
embeddings
feature request
feedback wanted
good first issue
gpt-oss
gpu
harmony
help wanted
image
install
intel
js
launch
linux
macos
memory
mlx
model
needs more info
networking
nvidia
ollama.com
performance
pull-request
Mirrored from GitHub Pull Request
 python
question
registry
rendering
thinking
tools
top
vulkan
windows
wsl
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/ollama#76858
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?