Skip to content

Conversation

@samizdatco
Copy link
Member

This PR tries to update PyObjC and the app's embedded Python interpreter to their current releases (as of May 2025), ideally without needing to change the minimum supported macOS version:

  • PyObjC: 11.0
  • Python: 3.13.3
  • macOS: 10.13+

Getting python3 setup.py app to run successfully required disabling the strip-symbols build step (a4fcc8e), leading to a slightly larger final app bundle. It would be nice to be able to reenable this, but I haven't been able to figure out what's causing the error (nor why the files it's having trouble with report containing PPC & x86 but not ARM code).

@flimsyhat, would you mind giving these changes a try and seeing if they build successfully for you (whether as a module for python 3.9+ or as an app)?

- `cgi` was removed in python 3.13 causing an import error
- `objc` is no longer reexported by Foundation so pull it in manually
- A number of the .so files installed by PyObjC trip up Xcode's `/usr/bin/strip`, failing with the error: `internal error: reloc_has_pair() called with unknown cputype (18)` if `COPY_STRIP_PHASE` is set to `YES`
- it's not clear to me whether this is a (temporary?) bug in Xcode 16.3 or something that should be fixed in the Python.framework build process…
@flimsyhat
Copy link
Contributor

Sure thing, will give this a try and let you know 👍

@flimsyhat
Copy link
Contributor

flimsyhat commented May 29, 2025

Can confirm that the build works for me.

For the strip-symbols issue, I think it's the legacy PPC binaries that come bundled with py2app that are tripping up Xcode 16. I was able to build successfully with COPY_PHASE_STRIP enabled after modifying the requirements to use py2app directly from the github master branch (which now uses universal 2) instead of the pypi version:

image

Another option is to build from Xcode 15: I tried and this works as well.

- Xcode was objecting to the legacy fat binaries in the prebuilt dirs
- now keeping only the `main-universal2` binary and reenabling symbol stripping in the production build process
@samizdatco
Copy link
Member Author

Thanks so much for tracking that down. I added a step to the Python.framework Makefile that deletes all the non-universal2 prebuilt binaries and that seems to have satisfied Xcode.

@samizdatco samizdatco merged commit d370c6a into main May 30, 2025
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants