Visitar URL original
Perf trampoline fails to build on macOS < 10.12 · Issue #140421 · python/cpython · GitHub
Skip to content

Perf trampoline fails to build on macOS < 10.12 #140421

Closed

Description

@jmroot

Bug report

Bug description:

The code uses clock_gettime which was added in macOS 10.12, and also MAP_ANONYMOUS which is sometimes spelled MAP_ANON. I was initially going to suggest just disabling this feature on the older systems, but actually fixing it for all x86 Macs turned out to be fairly simple, so I'll be opening a PR that does that shortly.

CPython versions tested on:

3.15

Operating systems tested on:

macOS

Linked PRs

Activity

  1. added
    type-bugAn unexpected behavior, bug, or error
    on Oct 21, 2025
  2. added a commit that references this issue on Oct 21, 2025
  3. hugovk commented on Oct 21, 2025

    @hugovk
    Member

    macOS 10.11 El Capitan is pretty old, it was EOL in 2018.

    macOS 10.12 Sierra was released in 2016, and the Python macOS installer supports 10.15 Catalina and later:

    https://docs.python.org/3/using/mac.html#using-python-for-macos-from-python-org

    But I'll let the JIT maintainers decide about this change.

  4. gpshead commented on Nov 11, 2025

    @gpshead
    Member

    Closing this as 10.12 has been unsupported by Apple for 6 years.

  5. jmroot commented on Nov 11, 2025

    @jmroot
    ContributorAuthor

    @gpshead Would you accept a patch to simply disable the feature where it won't build?

  6. barracuda156 commented on Jan 21, 2026

    @barracuda156

    @gpshead @hugovk This should be reconsidered. There are a lot of users of < 10.12, and pretty much all of them are using Python in some way (at least for dependents). @jmroot maintains Python ports in MacPorts for years, and unless you see an error in his fix, it is a good idea to accept it.

  7. hugovk commented on Jan 21, 2026

    @hugovk
    Member

    The oldest version of Python accepting bugfixes, and with a macOS installer, is 3.13. The 3.13 installer requires macOS 10.13 or later and

    3.14 requires 10.15 or later.

    That means if you're using Python for older macOS, you're already need to build from source, so can also patch as needed.

    I don't have numbers for how many < 10.12 users there are.

    To try and get an idea, here's a week's worth of PyPI downloads for urllib3, which is has a billion downloads per month and is the most-downloaded, non-AWS-specific package, so hard to avoid.

    Out of 283,920,840 total downloads, 3,153,585 or 1.1% are for macOS:

    Version Codename Downloads % (all) % (macOS) cumulative
    27 208 0.0001% 0.01% 0.01%
    26 Tahoe 973,712 0.3432% 30.87% 30.88%
    18 45 0.0000% 0.00% 30.88%
    17 45 0.0000% 0.00% 30.88%
    16 101 0.0000% 0.00% 30.89%
    15 Sequoia 1,549,977 0.5461% 49.15% 80.03%
    14 Sonoma 372,236 0.1300% 11.80% 91.84%
    13 Ventura 103,134 0.0364% 3.27% 95.11%
    12 Monterey 74,529 0.0265% 2.36% 97.47%
    11 Big Sur 10,028 0.0035% 0.32% 97.79%
    10.16 Big Sur 64,734 0.0230% 2.05% 99.84%
    10.15 Catalina 4,328 0.0015% 0.14% 99.98%
    10.14 Mojave 335 0.0001% 0.01% 99.99%
    10.13 High Sierra 336 0.0001% 0.01% 100.00%
    10.12 Sierra 25 0.0000% 0.00% 100.00%
    10.11 El Capitan 20 0.0000% 0.00% 100.00%
    Total 3,153,793 1.1108% 100.00% 100.00%
    • < 10.12 accounts for 45 20 downloads out of 3.1m
    • 3.13's 10.13+ accounts for ~100.00%
    • 3.14's 10.15+ accounts for 99.98%

    script-and-data.zip

  8. barracuda156 commented on Jan 21, 2026

    @barracuda156

    That means if you're using Python for older macOS, you're already need to build from source

    Of course; nobody asks for pre-compiled binaries for legacy macOS. But the same case is with a lot of platforms, including modern ones; I don’t think Python upstream provides pre-built pythons for every feasible combo of latest release of every OS and every arch supported by it.

    so can also patch as needed.

    Yes, but a) that leaves it broken for anyone who tries to build without MacPorts; b) multiple downstreams should either repeat the same work to fix it or find an existing fix across other downstreams; c) requires every downstream to keep rebasing a patch for likely completely unrelated changes in the source (i.e. there is zero maintenance effort for the upstream, but a lot of ongoing maintenance for every downstream).

  9. barracuda156 commented on Jan 21, 2026

    @barracuda156

    P. S. This also de-incentivizes potential contributors to submit any fixes later on, which won’t be limited to a platform that is not supported by upstream. This is an unseen consequence, but it is there.

  10. added a commit that references this issue on Feb 10, 2026
  11. added a commit that references this issue on Feb 11, 2026
  12. ned-deily commented on Feb 11, 2026

    @ned-deily
    Member

    Would you accept a patch to simply disable the feature where it won't build?

    Thanks for the PR. I think this is a minor but very low-risk change that makes life a bit easier for projects (like MacPorts) that support older macOS versions and older Mac hardware.

  13. added a commit that references this issue on Feb 15, 2026
  14. added a commit that references this issue on Feb 28, 2026
  15. added a commit that references this issue on Apr 25, 2026
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

    OS-macbuildThe build process and cross-buildtopic-JITtype-bugAn unexpected behavior, bug, or error

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions