A general wish not to disadvantage those with older hardware any more than they already are? Just a shot in the dark. On Wed, Dec 9, 2020 at 6:17 PM Gregory P. Smith <greg@krypto.org> wrote:
As a meta question: Is there a good reason to support binaries running on macOS earlier than ~ $latest_version-1?
Aren't systems running those old releases rather than upgrading unsupported by Apple, never to be patched, and thus not wise to even have on a network?
Yes, that means some very old hardware becomes useless as Apple drops support. But that is what people signed up for when they bought it. Why should that be our problem?
(It sounds like y'all will make it work, that's great! I'm really just wondering where the motivation comes from)
-gps
On Wed, Dec 9, 2020, 9:25 AM Gregory Szorc <gregory.szorc@gmail.com> wrote:
On Wed, Dec 9, 2020 at 4:13 AM Ronald Oussoren <ronaldoussoren@mac.com> wrote:
On 8 Dec 2020, at 19:59, Gregory Szorc <gregory.szorc@gmail.com> wrote:
Regarding the 3.8.7rc1 release, I wanted to raise some issues regarding macOS.
Without the changes from https://github.com/python/cpython/pull/22855 backported, attempting to build a portable binary on macOS 11 (e.g. by setting `MACOSX_DEPLOYMENT_TARGET=10.9`) results in a myriad of `warning: 'XXX' is only available on macOS 10.13 or newer [-Wunguarded-availability-new]` warnings during the build. This warning could be innocuous if there is run-time probing in place (the symbols in question are weakly linked, which is good). But if I'm reading the code correctly, run-time probing was introduced by commits like eee543722 and isn't present in 3.8.7rc1.
I don't have a machine with older macOS sitting around to test, but I'm fairly certain the lack of these patches means binaries built on macOS 11 will blow up at run-time when run on older macOS versions.
These same patches also taught CPython to build and run properly on Apple ARM hardware. I suspect some people will care about these being backported to 3.8.
We know. Backporting the relevant changes to 3.8 is taking more time than I had hoped. It doesn’t help that I’ve been busy at work and don’t have as much energy during the weekend as I’d like.
The backport to 3.9 was fairly easy because there were few changes between master and the 3.9 branch at the time. Sadly there have been conflicting changes since 3.8 was forked (in particular in posixmodule.c).
The current best practice for building binaries that work on macOS 10.9 is to build on that release (or rather, with that SDK). That doesn’t help if you want to build Universal 2 binaries though.
Thank you for your hard work devising the patches and working to backport them.
I personally care a lot about these patches and I have the technical competency to perform the backport. If you need help, I could potentially find time to hack on it. Just email me privately (or ping @indygreg on GitHub) and let me know. Even if they don't get into 3.8.7, I'll likely cherry pick the patches for https://github.com/indygreg/python-build-standalone. And I'm sure other downstream packagers will want them as well. So having them in an unreleased 3.8 branch is better than not having them at all. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/5AWFX2PO... Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/Q45VNQYO... Code of Conduct: http://python.org/psf/codeofconduct/