python / python/cpython

Allow static, non-framework iOS builds

Ouverte
#156,109 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

build OS-ios type-feature
Langage dominant
Python
Étoiles
77.2k
Forks
35.9k
Métriques de merge des PR
Métriques de PR en attente

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

Guide de contribution

Ouvrir le guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Piste de recherche

Commencez dans configure.ac aux lignes 582, 692, 3838 et 6767, puis comparez la gestion d’iOS avec celle de Darwin arm présentée à proximité. Vérifiez les combinaisons de configure shared et static décrites dans l’issue, confirmez que les builds de framework restent inchangés et vérifiez que le build statique produit bien libpython3.16.a.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Évaluation

Stack technique
python
Domaine
build-system, mobile-dev
Type d'issue
Fonctionnalité
Difficulté
3/5
Temps estimé
1-2 jours
Activité
À l'abandon
Clarté
Clairement spécifiée
Accessibilité débutants
25/100

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.