Repository navigation
Availability of utimensat, futimens not checked correctly on macOS #75782
Description
Activity
The futimens and utimensat functions are available in High Sierra but not previous versions of macOS. Building against the 10.13 SDK and deploying to an earlier version will result in a crash when the dynamic linker can't find the symbols at runtime. Availability of the symbols needs to be checked at runtime before use.
This was originally reported in <https://trac.macports.org/ticket/54893\>.
- addedbuildThe build process and cross-buildThe build process and cross-buildtype-crashA hard crash of the interpreter, possibly with a core dumpA hard crash of the interpreter, possibly with a core dump
on Sep 27, 2017 - changed the title
[-]Availability of utimensat and futimens not checked correctly on macOS[/-][+]Availability of utimensat,futimens not checked correctly on macOS[/+]on Sep 30, 2017 This is true for other symbols as well, when deploying to older releases of macOS.
I have added runtime checking for a number of symbols in the past, that could be extended to newer APIs.
--
On the road, hence brief.Op 30 sep. 2017 om 09:17 heeft Terry J. Reedy <report@bugs.python.org> het volgende geschreven:
Change by Terry J. Reedy <tjreedy@udel.edu>:
----------
components: +macOS
nosy: +ned.deily, ronaldoussoren
title: Availability of utimensat and futimens not checked correctly on macOS -> Availability of utimensat,futimens not checked correctly on macOS
Python tracker <report@bugs.python.org>
<https://bugs.python.org/issue31601\>
- changed the title
[-]Availability of utimensat,futimens not checked correctly on macOS[/-][+]Availability of utimensat, futimens not checked correctly on macOS[/+]on Sep 30, 2017 - addedbuildThe build process and cross-buildThe build process and cross-build3.7 (EOL)end of lifeend of lifeand removedbuildThe build process and cross-buildThe build process and cross-build
on Nov 16, 2018 This isn't just a cross-build issue, or rather (depending on how you look at it) cross-builds are increasingly the norm due to Apple only providing a newer SDK on older OS versions. For example the latest version of Xcode available for 10.12 only comes with the 10.13 SDK.
This issue blocks QGIS distribution on MacOS for 10.11 and 10.12 releases, https://github.com/lutraconsulting/qgis-mac-packager/issues/22
I would like to know how much work is involved to fix the issue, possible whether there is a plan to fix it. Also we would appreciate quote & timeline for fix to info@lutraconsulting.co.uk, so we can consider to sponsor this fix. Thanks
I ran into this with PyOxidizer. CPython's
configureneeds to be made aware of the current macOS SDK version and filter out symbols not present in the target macOS version. I worked around it byundef'ing some entries from the generatedpyconfig.hfile.macOS's clang does emit some warnings when it sees symbols that shouldn't be used with the current target version. CPython's build system should consider adding -Werror=unguarded-availability-new to CFLAGS to turn these warnings into errors so they are caught at compile time and not run time. But there should be proper filtering of affected symbols first, otherwise people won't be able to build CPython when targeting older macOS versions.
I'd prefer a solution that uses symbols where the are available (weak linking).
That way users on newer systems can use all functionality available there, without having multiple binaries.
I've done this in the past for older macOS versions, but don't know how involved such patches would be for current versions of CPython.
Looks like this is fixed as of 3.9.1.
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields: