Compile bug: Not compilable with MACOSX_DEPLOYMENT_TARGET < 10.15

[uwu-420]

Git commit

cfd74c8

Operating systems

Mac

GGML backends

CPU

Problem description & steps to reproduce

I'd like to compile llama.cpp for a MACOSX_DEPLOYMENT_TARGET=10.13 which is arguably sensible considering that projects like NumPy also still support this target, see e.g. https://pypi.org/project/numpy/#numpy-2.2.2-cp312-cp312-macosx_10_13_x86_64.whl and after all I hope that one of the goals of this project is to run LLMs at the edge, which frankly includes old Intel Macs for which people might have no other use :)

But recent commits use C++ functionality that is not supported by this macos target, so I kindly ask to consider setting a minimum supported macos deployment target, preferably 10.13, for this project. For example, this could be added as a CI step to check. Of course I understand that using Apple's Accelerate requires macos version >= 13.3 but in my example to reproduce I tried to strip down the compilation to the bare necessities but it still does not work.

I'd be interested in your opinions on this and hopefully this is something you could do. Thanks!

FYI @slaren

First Bad Commit

3420909

Compile command

mkdir build
cmake -B build -DCMAKE_OSX_DEPLOYMENT_TARGET="10.13" -DGGML_BLAS=OFF -DGGML_METAL=OFF -DLLAMA_BUILD_EXAMPLES=OFF
cmake --build build --config Release -j 6

Relevant log output

/Users/user/llama.cpp/ggml/src/ggml-backend-reg.cpp:505:18: error: 'exists' is unavailable: introduced in macOS 10.15
  505 |         if (!fs::exists(search_path)) {
      |                  ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX15.0.sdk/usr/include/c++/v1/__filesystem/operations.h:152:35: note: 'exists' has been explicitly marked unavailable here
  152 | inline _LIBCPP_HIDE_FROM_ABI bool exists(const path& __p) { return exists(__status(__p)); }
      |

[slaren]

From what I could find, macOS 10.15 is supported in devices made in 2012 and later, so I am not sure that it would be worth the effort. But nonetheless, if you care about this enough to rewrite and maintain the std::filesystem code with system-specific alternatives, go for it.