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.sz...@gmail.com> wrote: > On Wed, Dec 9, 2020 at 4:13 AM Ronald Oussoren <ronaldousso...@mac.com> > wrote: > >> >> >> On 8 Dec 2020, at 19:59, Gregory Szorc <gregory.sz...@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-le...@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/5AWFX2POTPNVW72VUPCPTJIOA6AOSVWY/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/Q45VNQYOYXTRRTA26Q4M2WNXPFKL4S2O/ Code of Conduct: http://python.org/psf/codeofconduct/
