PR #15550: gemma4: fix compiler error on metal

• Repository: ollama/ollama
• Author: dhiltgen
• State: closed | merged: True
• Link: https://github.com/ollama/ollama/pull/15550

Description (problem / solution / changelog)

On some systems, the metal runtime compiler is failing due to an uninitialized variable from #15378.

Fixes #15548

Changed files

• llama/patches/0027-interleave-multi-rope.patch (modified, +11/-8)
• llama/patches/0032-ggml-enable-MLA-flash-attention-for-GLM-4.7-flash.patch (modified, +1/-1)
• llama/patches/0033-ggml-metal-solve_tri.patch (modified, +1/-1)
• llama/patches/0034-ggml-metal-guard-mul_mat_id-map0-and-add-ne20-22-spe.patch (modified, +1/-1)
• llama/patches/0036-backport-kernels-for-gemma4.patch (modified, +1/-1)
• ml/backend/ggml/ggml/src/ggml-metal/ggml-metal-embed.metal (modified, +1/-1)
• ml/backend/ggml/ggml/src/ggml-metal/ggml-metal.metal (modified, +1/-1)

PR #15551: app: restore macOS runtime env for managed server

• Repository: ollama/ollama
• Author: Horacehxw
• State: open | merged: False
• Link: https://github.com/ollama/ollama/pull/15551

Description (problem / solution / changelog)

Summary

Restore selected runtime environment variables from launchctl getenv when the macOS desktop app launches a managed ollama serve process.

On Apple Silicon macOS setups, users can configure runtime workarounds such as:

• GGML_METAL_TENSOR_DISABLE=1
• OLLAMA_KV_CACHE_TYPE=q8_0
• OLLAMA_FLASH_ATTENTION=1

These may be present in the user's launchd session, but not in the desktop app process environment. In that case the managed serve child never sees them, even though server.cmd() already copies os.Environ().

This patch adds a small darwin-only fallback: for a narrow allowlist of runtime env vars, if a key is missing from the app process env, read it from launchctl getenv and inject it into the managed server env.

Why this change

I reproduced a case on Apple M5 Pro + macOS 26.4 + Ollama 0.20.6 where:

• launchctl print gui/$(id -u)/com.ollama.ollama showed GGML_METAL_TENSOR_DISABLE=1
• but /Applications/Ollama.app/Contents/Resources/ollama serve did not have that env in ps eww
• and model loads failed with Metal compile errors and 500

Typical failing log sequence:

• ggml_metal_device_init: has tensor = true
• ggml_metal_init: the device does not have a precompiled Metal library - this is unexpected
• ggml_metal_init: will try to compile it on the fly
• MPPTensorOpsMatMul2dImpl.h ... static_assert failed due to requirement '__is_same_v<bfloat, half>'
• SIGABRT: abort

With GGML_METAL_TENSOR_DISABLE=1, the same machine can load the model successfully.

Scope

This intentionally does not introduce generic env passthrough logic.

It only restores a small allowlist of documented runtime env vars plus GGML_METAL_TENSOR_DISABLE, and only when the variable is absent from the current process env.

Explicit process env still wins.

Tests

Added coverage for:

• filling missing allowlisted variables from launchctl
• preserving explicit process env over launchctl values
• ignoring missing/empty launchctl values
• ensuring Server.cmd() includes recovered values in cmd.Env

Verification

Passed locally:

go test ./app/server

Related

• Closes or helps with: #15548

Changed files

• app/server/server.go (modified, +1/-0)
• app/server/server_darwin_env.go (added, +58/-0)
• app/server/server_test.go (modified, +129/-0)
• app/server/server_windows_env.go (added, +5/-0)