Allow static, non-framework iOS builds
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 77.2k
- Forks
- 35.9k
- PR merge metrics
- PR metrics pending
Description
Feature or enhancement
Proposal:
configure refuses any iOS build that is not a framework build, in both the explicit and the default path:
configure.ac:582 iOS) AC_MSG_ERROR([iOS builds must use --enable-framework]) ;; # --disable-framework
configure.ac:692 iOS) AC_MSG_ERROR([iOS builds must use --enable-framework]) ;; # no framework option given
The requirement is sound for a shared Python: an iOS app can only load a signed framework, never a bare dylib, so a dynamically loaded libpython has to be packaged as one. It does not hold for a static one. A --disable-shared build produces libpython3.x.a, which is linked into the app binary and loads nothing at runtime, so there is no framework to sign, package or load — but configure rejects that configuration before it can be attempted.
This matters for embedders, which link libpython statically into a single signed executable. Today they have to either patch configure locally or give up sys.platform == "ios" and cross-build as Darwin, which misreports the platform to the stdlib.
Two other places assume the framework exists whenever ac_sys_system is iOS:
configure.ac:3838 LINKFORSHARED="… $(PYTHONFRAMEWORKDIR)/$(PYTHONFRAMEWORK)"
configure.ac:6767 MODULE_DEPS_SHARED="… $(PYTHONFRAMEWORKDIR)/$(PYTHONFRAMEWORK)"
The Darwin arm immediately above the first one already guards the identical append with if test "$enable_framework"; the iOS arm does it unconditionally.
Suggested shape, keeping the change conservative:
- refuse only the combination that genuinely cannot work — a shared build with no framework — checked once
PY_ENABLE_SHAREDis known; - gate the two framework appends on
enable_framework, matching the Darwin arm; - leave the default path (no framework option at all) erroring, so a non-framework build stays an explicit opt-in, with the message naming
--disable-framework.
I have this working against main and will open a PR. Verified locally on macOS/arm64:
--host=arm64-apple-ios12.0 --disable-shared --disable-frameworkconfigures andmake libpython3.16.asucceeds, producing an arm64 archive withLC_BUILD_VERSION platform 2, minos 12.0;--disable-framework --enable-sharedis rejected with the new message;- no framework option is still rejected;
--enable-frameworkproduces a byte-identicalMakefileandpyconfig.hto unpatchedmain, so the supported framework build is unaffected.
Has this already been discussed elsewhere?
This is a minor feature, which does not need previous discussion elsewhere
Links to previous discussion of this feature:
No response
Linked PRs
- gh-156110
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in configure.ac at lines 582, 692, 3838, and 6767, then compare the iOS handling with the Darwin arm shown nearby. Verify the shared and static configure combinations described in the issue, confirm framework builds remain unchanged, and check that the static build produces libpython3.16.a successfully.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- build-system, mobile-dev
- Issue type
- Feature
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Clearly specified
- Newbie friendliness
- 25/100