> On 9 Dec 2020, at 19:10, Gregory P. Smith <g...@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?
There’s no documented policy about which versions are supported, but N-2 would be a good guess (even if Apple mostly just publishes patches for N-1). What worries me a little about dropping older macOS versions is that I haven’t found good information about upgrade rates, but have seen annecdotes about users not upgrading or upgrading late. That said. We support older versions because its fairly easy to do and to keep supporting users stuck at older versions for other reasons. > > 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) The basic work is needed for N-1 (build on macOS 11, deploy to 10.15), doing the same for macOS 10.9 was fairly straightforward. This is work that needs to be done once, and is clearly labelled after that (making it easy to identify when we decide to move the minimal version forward). One reason to support 10.9 for the universal2 installers is that this allows us to move all users over, the universal2 installer can be used on all systems where the current x86_64 installers can be used and should be faster because we also (finally) enabled LTO/PGO for the macOS installer. BTW. Removing support for old versions is also work. The universal2 patches finally dropped support for weak linking a couple of APIs that were introduced in macOS 10.4, which we haven’t supported in a very long while. Ronald > > -gps > > On Wed, Dec 9, 2020, 9:25 AM Gregory Szorc <gregory.sz...@gmail.com > <mailto:gregory.sz...@gmail.com>> wrote: > On Wed, Dec 9, 2020 at 4:13 AM Ronald Oussoren <ronaldousso...@mac.com > <mailto:ronaldousso...@mac.com>> wrote: > > >> On 8 Dec 2020, at 19:59, Gregory Szorc <gregory.sz...@gmail.com >> <mailto: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 >> <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 > <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 > <mailto:python-dev@python.org> > To unsubscribe send an email to python-dev-le...@python.org > <mailto:python-dev-le...@python.org> > https://mail.python.org/mailman3/lists/python-dev.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/ > > <https://mail.python.org/archives/list/python-dev@python.org/message/5AWFX2POTPNVW72VUPCPTJIOA6AOSVWY/> > Code of Conduct: http://python.org/psf/codeofconduct/ > <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/K5WTYH4EL3XJE4YNDRC6334U3GMBOPRN/ Code of Conduct: http://python.org/psf/codeofconduct/
