Repository navigation
Availability of utimensat, futimens not checked correctly on macOS #75782
Description
| BPO | 31601 |
|---|---|
| Nosy | @ronaldoussoren, @ned-deily, @jmroot, @moreati, @indygreg |
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:
assignee = None
closed_at = <Date 2020-12-08.10:25:06.093>
created_at = <Date 2017-09-27.06:23:40.145>
labels = ['build', '3.7', 'type-crash']
title = 'Availability of utimensat, futimens not checked correctly on macOS'
updated_at = <Date 2020-12-08.10:25:06.092>
user = 'https://github.com/jmroot'bugs.python.org fields:
activity = <Date 2020-12-08.10:25:06.092>
actor = 'jmr'
assignee = 'none'
closed = True
closed_date = <Date 2020-12-08.10:25:06.093>
closer = 'jmr'
components = ['Cross-Build']
creation = <Date 2017-09-27.06:23:40.145>
creator = 'jmr'
dependencies = []
files = []
hgrepos = []
issue_num = 31601
keywords = []
message_count = 7.0
messages = ['303098', '303386', '330010', '330122', '349515', '349537', '382722']
nosy_count = 7.0
nosy_names = ['ronaldoussoren', 'ned.deily', 'jmr', 'Alex.Willmer', 'indygreg', 'Peter Petrik', 'Peter Petrik2']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'crash'
url = 'https://bugs.python.org/issue31601'
versions = ['Python 3.5', 'Python 3.6', 'Python 3.7']
Activity
jmroot commentedon Sep 27, 2017
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\>.
[-]Availability of utimensat and futimens not checked correctly on macOS[/-][+]Availability of utimensat,futimens not checked correctly on macOS[/+]ronaldoussoren commentedon 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:
[-]Availability of utimensat,futimens not checked correctly on macOS[/-][+]Availability of utimensat, futimens not checked correctly on macOS[/+]jmroot commentedon 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.
PeterPetrik2 commentedon Nov 20, 2018
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
indygreg commentedon Aug 13, 2019
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.
ronaldoussoren commentedon Aug 13, 2019
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.
jmroot commentedon Dec 8, 2020
Looks like this is fixed as of 3.9.1.