Skip to content

Availability of utimensat, futimens not checked correctly on macOS #75782

Description

@jmroot
mannequin
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

  1. jmroot commented on Sep 27, 2017

    jmrootmannequin
    MannequinAuthor

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

  2. added
    buildThe build process and cross-build
    type-crashA hard crash of the interpreter, possibly with a core dump
    on Sep 27, 2017
  3. 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
  4. ronaldoussoren commented on Sep 30, 2017

    @ronaldoussoren
    Contributor

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


  5. 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
  6. added
    buildThe build process and cross-build
    and removed
    buildThe build process and cross-build
    on Nov 16, 2018
  7. jmroot commented on Nov 16, 2018

    jmrootmannequin
    MannequinAuthor

    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.

  8. PeterPetrik2 commented on Nov 20, 2018

    PeterPetrik2mannequin
    Mannequin

    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

  9. indygreg commented on Aug 13, 2019

    indygregmannequin
    Mannequin

    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.

  10. ronaldoussoren commented on Aug 13, 2019

    @ronaldoussoren
    Contributor

    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.

  11. jmroot commented on Dec 8, 2020

    jmrootmannequin
    MannequinAuthor

    Looks like this is fixed as of 3.9.1.

  12. transferred this issue fromon Apr 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    3.7 (EOL)end of lifebuildThe build process and cross-buildtype-crashA hard crash of the interpreter, possibly with a core dump

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions