mlx-c 0.6.0_1 fails with CMake Error at /opt/local/share/cmake/MLX/MLXConfig.cmake:49

[breun (Nils Breunese)]

I have mlx-c 0.6.0_0 installed, but the update to 0.6.0_1 on macOS 26.5.1 arm64 fails for me with:

:info:configure -- Detecting C compile features - done
:info:configure CMake Error at /opt/local/share/cmake/MLX/MLXConfig.cmake:49 (if):
:info:configure   if given arguments:
:info:configure     "GREATER_EQUAL" "310"
:info:configure   Unknown arguments specified
:info:configure Call Stack (most recent call first):
:info:configure   CMakeLists.txt:33 (find_package)
:info:configure -- Configuring incomplete, errors occurred!

Line 49 of /opt/local/share/cmake/MLX/MLXConfig.cmake looks like this:

if( GREATER_EQUAL 310)

It looks like something is missing before GREATER_EQUAL?

[neverpanic (Clemens Lang)]

First: It doesn't happen on my machine, for me the line is

    if(320 GREATER_EQUAL 310)

Second, the template for that file is mlx.pc.inin the build tree and contains this:

    if(@MLX_METAL_VERSION@ GREATER_EQUAL 310)
      set(MLX_INCLUDE_DIRS
        "${MLX_INCLUDE_DIRS};"
        @PACKAGE_CMAKE_INSTALL_INCLUDEDIR@/mlx/backend/metal/kernels/metal_3_1)
    else()
      set(MLX_INCLUDE_DIRS
        "${MLX_INCLUDE_DIRS};"
        @PACKAGE_CMAKE_INSTALL_INCLUDEDIR@/mlx/backend/metal/kernels/metal_3_0)
    endif()

So what's happening here is that MLX_METAL_VERSION is not defined in your build.

The way that variable is supposed to be set in MLX' CMakeLists.txt is this:

  execute_process(
    COMMAND
      zsh "-c"
      "echo \"__METAL_VERSION__\" | xcrun -sdk macosx metal ${XCRUN_FLAGS} -E -x metal -P - | tail -1 | tr -d '\n'"
    OUTPUT_VARIABLE MLX_METAL_VERSION COMMAND_ERROR_IS_FATAL ANY)

It seems that command doesn't actually fail when you have no working metal toolchain, either because the Shell hides it (this could potentially be fixed, but I don't use zsh and don't know how), or because xcrun -sdk macosx metal should fail with an exit code when the toolchain isn't installed but doesn't.

In any case, I believe what happened here is that your metal toolchain doesn't work correctly. You should have seen the following two lines when the build started, please follow them:

If the build fails, make sure you have a metal toolchain installed; run `sudo xcodebuild -downloadComponent MetalToolchain` to do so.
If you already have the metal toolchain installed but the build still fails, see https://trac.macports.org/wiki/TahoeProblems#MetaltoolchainisnolongerbundledinXcode.

[breun (Nils Breunese)]

The Metal toolchain is actually installed on my machine:

❯ xcrun metal --version
Apple metal version 32023.883 (metalfe-32023.883)
Target: air64-apple-darwin25.5.0
Thread model: posix
InstalledDir: /private/var/run/com.apple.security.cryptexd/mnt/com.apple.MobileAsset.MetalToolchain-v17.6.42.0.2UgAVI/Metal.xctoolchain/usr/metal/current/bin

Executing that command in a shell does return output:

❯ zsh "-c" "echo \"__METAL_VERSION__\" | xcrun -sdk macosx metal ${XCRUN_FLAGS} -E -x metal -P - | tail -1 | tr -d '\n'"
400%

P.S. I maintain the openjdk* ports, which also require the Metal toolchain to build, and I got the advice from Mark Mentovai (who did the work that led to ​https://trac.macports.org/wiki/TahoeProblems#MetaltoolchainisnolongerbundledinXcode) to patch away -sdk macosx, because MacPorts sets the SDK, which may be different from this default. I'm working on a general Metal toolachin check with actionable advice in ​https://github.com/macports/macports-ports/pull/32889, which I eventually hope to turn into a reusable metal PortGroup.

[neverpanic (Clemens Lang)]

Replying to breun:

Executing that command in a shell does return output:

❯ zsh "-c" "echo \"__METAL_VERSION__\" | xcrun -sdk macosx metal ${XCRUN_FLAGS} -E -x metal -P - | tail -1 | tr -d '\n'"
400%

Hm, maybe it's due to version 400… I still get 320.

P.S. I maintain the openjdk* ports, which also require the Metal toolchain to build, and I got the advice from Mark Mentovai (who did the work that led to ​https://trac.macports.org/wiki/TahoeProblems#MetaltoolchainisnolongerbundledinXcode) to patch away -sdk macosx, because MacPorts sets the SDK, which may be different from this default.

OK, so that also rules out that your metal toolchain only works under your user but not under macports (which apparently is also a problem as documented in the FAQ, and I've also seen it).

The SDK is likely not a problem for MLX, because the port explicitly sets it to the result of xcrun --show-sdk-version overriding the MacPorts default, and that's also what the CMakeLists.txt does.

I'm working on a general Metal toolachin check with actionable advice in ​https://github.com/macports/macports-ports/pull/32889, which I eventually hope to turn into a reusable metal PortGroup.

Thanks, that's much appreciated.

[briankennison]

I have the exact same output as above, mlx builds but not mlx-c. Is there a resolution to this problem that I am missing? Thank you for your time.