[issue34597] Python needs to check existence of functions at runtime for targeting older macOS platforms
Zorg added the comment: I understand that. I was mainly responding to a question that was asked with information I felt was important to provide. -- ___ Python tracker <https://bugs.python.org/issue34597> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34597] Python needs to check existence of functions at runtime for targeting older macOS platforms
Zorg added the comment: Also more obviously: it's less convenient for others keeping themselves up to date to set up an older development environment. -- ___ Python tracker <https://bugs.python.org/issue34597> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34597] Python needs to check existence of functions at runtime for targeting older macOS platforms
Zorg added the comment: > Why do you believe that is safer? Apple goes to great lengths to provide > compatibility for existing applications to keep running on newer systems. They also don't want developers to develop using older SDKs. Hypothetically speaking, more information may be stored in the binaries, and there could be something down the road to opt into that requires all binaries to be linked against a certain SDK. Or your code takes an older path based on the SDK version at runtime -- python may include some other higher level baggage too, like the tkinter stuff for instance. There is some middle ground other than weak linking; stripping out features from the configure part of the project and opt in to using the deprecated APIs. Not as ideal as weak linking, but better than building on an older SDK IMO. -- ___ Python tracker <https://bugs.python.org/issue34597> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34597] Python needs to check existence of functions at runtime for targeting older macOS platforms
Zorg added the comment: https://bugs.python.org/issue31359 has a better details about this issue. I personally believe it's safer to link against a newer SDK and deal with the trouble of finding out what to strip out, which will be opted into implications or code paths that linking a binary against a newer SDK may provide. -- ___ Python tracker <https://bugs.python.org/issue34597> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34597] Python needs to check existence of functions at runtime for targeting older macOS platforms
Zorg added the comment: The minimum OS target (which looks like 10.13) should ideally be well defined and tested using the latest SDK, rather than there being "no promises". Or at least it should be documented that this isn't currently supported, or how to disable specific features and which ones to disable. I downloaded the source tarball from https://www.python.org/downloads/release/python-370/ Python then isn't viable currently for embedding inside applications (https://docs.python.org/3/extending/embedding.html). 3rd party app developers on macOS typically have a policy at least supporting back to N-1 or N-2'th OS, and in many cases it shouldn't be their dependencies that drive this. The other two functions require 10.13: futimens utimensat Fortunately the -Wunguarded-availability warning is enabled which spits out warnings on which functions aren't available when targeting a min OS (MACOSX_DEPLOYMENT_TARGET) Can't say I can contribute anything here unfortunately :(. I had to do something though, so I hacked the configure scripts and pyconfig.h to make sure the clock_* and the above functions I mentioned above weren't being used. getentropy was easy to fix more properly because it already has a fallback at runtime in case it's not working, so it was just an additional NULL check. Looks like the functions are weakly referenced when building to an older OS target. A bad step in future direction would be to continue making "no promises" and start using functionality only available on 10.14, 10.15, etc without fallback. -- ___ Python tracker <https://bugs.python.org/issue34597> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34597] Python needs to check existence of functions at runtime for targeting older macOS platforms
New submission from Zorg : If one wants to compile Python and embed it in their applications, or more generally, deploy the framework / libraries to older systems, then Python needs to check the existence of functions at runtime that are unavailable to Python's supported minimum OS. For example, Python makes use of: clock_gettime getentropy These functions are only available on macOS 10.12. Python currently states it supports 10.9. Checking for their existence at compile time isn't good enough; compiling Python on 10.13 and deploying back to 10.9 or 10.11 for example will not work, and cause a crash at runtime. One can make sure the functions are weakly linked and check they aren't NULL to get around this. There may be more such functions Python is using; I haven't extensively searched for all usages. Alternatively, Python could state that it does not properly support embedding (probably not desirable), or Python could bump the minimum supported OS requirements in its documentation. Else one might be able to compile Python by turning off such features? But the user needs to know what those are, Python gives no warnings when MACOSX_DEPLOYMENT_TARGET/--mmacosx-version-min are low enough, and Python wouldn't be able to use those functions when they are actually available on newer systems. -- components: macOS messages: 324698 nosy: Zorg, ned.deily, ronaldoussoren priority: normal severity: normal status: open title: Python needs to check existence of functions at runtime for targeting older macOS platforms type: crash versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue34597> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
