Availability of utimensat, futimens not checked correctly on macOS

[jmroot]

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']

[jmroot]

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\>.

[ronaldoussoren]

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\>

---

[jmroot]

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]

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]

I ran into this with PyOxidizer. CPython's configure needs 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 by undef'ing some entries from the generated pyconfig.h file.

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]

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]

Looks like this is fixed as of 3.9.1.