python / python/cpython

Allow static, non-framework iOS builds

Open
#156,109 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

build OS-ios type-feature
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_SHARED is 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-framework configures and make libpython3.16.a succeeds, producing an arm64 archive with LC_BUILD_VERSION platform 2, minos 12.0;
  • --disable-framework --enable-shared is rejected with the new message;
  • no framework option is still rejected;
  • --enable-framework produces a byte-identical Makefile and pyconfig.h to unpatched main, 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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.