iOS issues

[henryiii]

Description

I was trying to use CMake on iOS (it's one of the examples for xbuild-tools, but I get this message:

  CMake Error: Could not find CMAKE_ROOT !!!
  CMake has most likely not been installed correctly.
  Modules directory not found in
  
  CMake Error: Error executing cmake::LoadCache(). Aborting.

It seems to not to be able to find and load the built-in modules directory.

CC @freakboy3742

Build log

https://github.com/scikit-hep/boost-histogram/actions/runs/15335417534/job/43151563524?pr=1016

CI config

https://github.com/scikit-hep/boost-histogram/blob/3348dd6d26b18db127076cb3c3d8ed1b6eed7528/pyproject.toml

[freakboy3742]

This sounds very similar to the problem I reported in the PR adding support for xbuild-tools. Based on @mayeut's comment, this was a known issue with a homebrew version of cmake, and was fixed in cmake 4.0

[henryiii]

Perfect, upgrading cmake made it past to:

  /private/var/folders/w5/_8wgjw3j5cg6mgrth3s2kg9m0000gn/T/build-env-wnt9kv8_/lib/python3.13/site-packages/pybind11/include/pybind11/detail/internals.h:331:16: error: thread-local storage is not supported for the current target
          static thread_local std::unique_ptr<InternalsType> *t_internals_pp = nullptr;
                 ^
  /private/var/folders/w5/_8wgjw3j5cg6mgrth3s2kg9m0000gn/T/build-env-wnt9kv8_/lib/python3.13/site-packages/pybind11/include/pybind11/detail/internals.h:332:16: error: thread-local storage is not supported for the current target
          static thread_local PyInterpreterState *istate_cached = nullptr;
                 ^
  2 errors generated.

So looks like I need to set up iOS testing for pybind11. Guessing I'll do it with cibuildwheel if I can (I do that for pyodide, so should be able to).

What's the status of free-threading and subinterpreters on iOS? This is part of the subinterpter support. Also, can one set the min iOS version?

We might want to add a note in the docs until GHA upgrades their images (hopefully they won't stick to 3.x too long!).

[freakboy3742]

Perfect, upgrading cmake made it past to:

  /private/var/folders/w5/_8wgjw3j5cg6mgrth3s2kg9m0000gn/T/build-env-wnt9kv8_/lib/python3.13/site-packages/pybind11/include/pybind11/detail/internals.h:331:16: error: thread-local storage is not supported for the current target
          static thread_local std::unique_ptr<InternalsType> *t_internals_pp = nullptr;
                 ^
  /private/var/folders/w5/_8wgjw3j5cg6mgrth3s2kg9m0000gn/T/build-env-wnt9kv8_/lib/python3.13/site-packages/pybind11/include/pybind11/detail/internals.h:332:16: error: thread-local storage is not supported for the current target
          static thread_local PyInterpreterState *istate_cached = nullptr;
                 ^
  2 errors generated.

That's a very familiar error to me: it indicates that you haven't got IPHONEOS_DEPLOYMENT_TARGET set in your build environment (or, at least, it's not being passed down to the context that is running clang++).

The thread_local keyword wasn't available on iOS until iOS 7; and if you don't specify a minimum iOS version, it assumes it's building for iOS 1. In the context of a numpy build, it needs to be passed in as a CIBW_ENVIRONMENT value

So looks like I need to set up iOS testing for pybind11. Guessing I'll do it with cibuildwheel if I can (I do that for pyodide, so should be able to).

What's the status of free-threading and subinterpreters on iOS? This is part of the subinterpter support. Also, can one set the min iOS version?

Subinterpreters work fine, and are tested as part of a standard CI run on CPython.

I haven't tried free-threading yet (it's on a long list of stuff I need to test out...). However, I'm not aware of any reason it shouldn't work (other than the normal free-threading-headache sort of issues).

[henryiii]

Is iOS 1 fine for CPython? I know we set minimum versions for the user for macOS based on CPython's needs (10.9, 10.13, or 11). Maybe we should do the same for iOS? Isn't there some minimum for 64 bit iOS?

[henryiii]

Also, are there iOS numpy wheels in a wheelhouse somewhere?

[freakboy3742]

Is iOS 1 fine for CPython? I know we set minimum versions for the user for macOS based on CPython's needs (10.9, 10.13, or 11). Maybe we should do the same for iOS? Isn't there some minimum for 64 bit iOS?

A CPython build for iOS defaults to a minimum iOS version of 13.0 - that's the lowest version that will build CPython without any warnings. However, the minimum version is configurable at build time. 12.0 will build, but with some warnings about SQLite features. Earlier versions might be possible to support, but I haven't tested; however, it's highly unlikely it will work for any version early than iOS 8, as that was the first release to allow apps to dynamically load libraries. iOS 14 was the first release that was 64-bit only.

In practice, an iOS 13 minimum covers something like 98% of all iPhone users; and you need iOS 16.4 or newer to use the Accelerate implementation of BLAS/LINPACK.

As for enforcing an IPHONEOS_DEPLOYMENT_TARGET value - cibuildwheel already does put IPHONEOS_DEPLOYMENT_TARGET in the environment. I'm not sure why that wouldn't be picked up in the pybind11 case.

Also, are there iOS numpy wheels in a wheelhouse somewhere?

I've got some quite old numpy versions here; I've been holding off publishing more recent versions while all the meson et al changes land.

[henryiii]

Not working for me (now on pybind11 adding a job for iOS) even set to 17: https://github.com/pybind/pybind11/actions/runs/15340789425/job/43166409369

[freakboy3742]

Ah - wait - this might be a manifestation of python/cpython#133183. In which case, it's another reason I need to push out updates to the iOS support packages.

[joerick]

@freakboy3742 do you have a timeline for that? i'm wondering if we want to hold up releasing v3.0 until we have the updated support package.

[henryiii]

Is there a way to detect this when compiling C/C++ code? I'd like to say "if compiling for iOS and deployment target is less than 17 (assuming you meant 17 not 7?), don't enable support for subinterpreters" in pybind11 (for now).

[freakboy3742]

@freakboy3742 do you have a timeline for that? i'm wondering if we want to hold up releasing v3.0 until we have the updated support package.

We definitely want to release v3.0 with the new support package; I'll put the support package at the top of my todo list for today.

Is there a way to detect this when compiling C/C++ code? I'd like to say "if compiling for iOS and deployment target is less than 17 (assuming you meant 17 not 7?), don't enable support for subinterpreters" in pybind11 (for now).

I definitely meant iOS 7, not 17. The standard CPython build is compiled for iOS 13, and it runs all the subinterpreter tests that don't involve using subprocesses.

As for detection - I'm not sure exactly what sort of detection you're thinking of. "The build environment must define IPHONEOS_DEPLOYMENT_TARGET, and it must be >= 7 (and in practice, >=13)" is the only real restriction here; and that should be passed through correctly (noting the fix to come in the next support package).

[henryiii]

CPython's TLS works fine, pybind11 uses that already, it's just C/C++'s thread_local that's a problem currently. We are trying a rewrite that uses the Python TLS implementation for subinterpreters too, I'll let you know if it works.

If 13+ is normally required, and thread_local works in 7+, that's great, and only a "currently" issue. I don't currently don't know how to set up a unit test (or anything outside of cibuildwheel) for iOS to check. (for Pyodide and now iOS, I'm using cibuildwheel and scikit-build-core to test pybind11).

For detection, I meant "can I write a #if <thing> that tells me that I'm compiling for iOS, and what version of iOS is targeted?". I wanted to disable subinterperters on versions that didn't support it. But if it's normally not a problem modulo a bug that will soon be fixed, that's not an issue, and I think we will get our rewrite in and it won't be an issue regardless.

[freakboy3742]

For detection, I meant "can I write a #if <thing> that tells me that I'm compiling for iOS, and what version of iOS is targeted?".

To check if you're on iOS at all, you can use:

#ifdef __APPLE__
#include <TargetConditionals.h>
#endif 
...
#if TARGET_OS_IOS

If you also want to target tvOS, watchOS, and visionOS, you can use TARGET_OS_IPHONE

To check for a specific version, of iOS, you can use:

#ifdef __APPLE__
#include <AvailabilityMacros.h>
#endif 
...
#if __IPHONE_OS_VERSION_MIN_REQUIRED >= __IPHONE_7_0

You may also need to do some defined() checks for those symbols, depending on which other platforms you want to support at the same time.

---

Regarding the updated iOS support package - the best laid plans of mice and men etc... I've hit the dual complications of an issue with the build tooling that creates the support package, and some other fires that have arisen this morning that have prevented me from fixing those problems. I'm hoping I'll be able to resolve both of these by tomorrow and get an updated package released.

[henryiii]

That's fine, I think we can get a beta/RC out soon, then get this in for the final release in a couple of days. That's likely to be the criteria for the final release, probably. :)

(And that was exactly what I was wanting to know, thanks!)