-
-
Notifications
You must be signed in to change notification settings - Fork 30.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
gh-100384: Error on unguarded-availability
in Darwin builds
#128155
Conversation
689e20a
to
6fd3184
Compare
I set the deployment target to 10.9 and 🎉 we catch the unguarded symbol. I guess ideally it'd be 10.3 since that's the stated minimum but compilation fails for that on my machine. I'm happy to debate what the minimum should be, but perhaps we should open a dedicated issue for that discussion? Using 10.9 instead of 10.15 catches symbols that have been reported as bugs recently, so I don't think going to 10.15 here makes sense. This pull request is now blocked on #128156 or reversion of 0f4b63e — I'm fine with either as long as we follow-up with something like 0f4b63e. |
The current releases of Apple's Xcode and Command Line Tools now only fully support building for deployment targets of 10.13 or newer and we should be testing with that. There are older versions of Xcode available in the the Github Actions macOS images. We may need to set up a different build to test with older deployment targets. This requires some more investigation and thought. |
configure.ac
Outdated
@@ -2603,6 +2603,13 @@ AS_VAR_IF([ac_cv_gcc_compat], [yes], [ | |||
esac | |||
AC_MSG_RESULT([$CC]) | |||
# Error on unguarded use of new symbols, which will fail at runtime for | |||
# users on older versions of macOS | |||
AX_CHECK_COMPILE_FLAG([-Wunguarded-availability-new], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As noted elsewhere, I think we should use unguarded-availability
here, not -new
but I want to test this on older systems which I won't be able to do for several more days.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done in 2ddda3a. This did not change the output on my machine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(or in CI)
A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated. Once you have made the requested changes, please leave a comment on this pull request containing the phrase |
Done in 24ee4a7 though we may want to just bump to 10.15 per #128156 (comment) |
@@ -0,0 +1,2 @@ | |||
Error on ``unguarded-availability-new`` in Darwin builds, preventing invalid |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
unguarded-availability-new
-> unguarded-availability
Darwin
-> macOS
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! 88ea223
Oh, sorry, we're clearly going to need to do that in this PR otherwise all macOS CI checks will fail. |
@ned-deily yeah, I wasn't sure if we wanted to try to solve #128156 before merging this but I'm happy to just bump to 10.15 then consider support for older versions separately? |
unguarded-availability-new
in Darwin buildsunguarded-availability
in Darwin builds
Yes, let's go with macOS 10.15 for Python 3.14 for now. For the record, this applies to "portable" builds, that is, built on a new version of macOS and run on a different (older) version of macOS. While not explicitly tested on older releases, configuring (without a MACOS_DEPLOYMENT_TARGET), building, and running on the same system should work with any particular version of macOS. I think a next step here is to propose an explicit CPython macOS support policy for 3.14 as a PEP, something that has been in the queue for awhile, and include with it details on supported "portable" ranges (like building on macOS 15 with a deployment target of 10.15) and with which universal architectures, to be backed up by GHA and/or buildbots CI testing. Having that should make making implementation decisions easier. I'll try to get to that later this week when I again have access to older macOS systems. |
P.S. Thanks, @zanieb, for all your work on this! |
…ython#128155) Generate a build error on ``unguarded-availability`` in portable macOS builds (i.e. using MACOSX_DEPLOYMENT_TARGET), preventing invalid use of symbols that are not available in older versions of the OS.
Closes #100384
This prevents introduction of unguarded use of symbols that would fail on older systems.
The build system purports to support macOS 10.3+, but the GitHub runners default Xcode version only supports 10.13+ and #128156 means 10.15+ is required. Here, we set that as the target in CI.
-Werror=unguarded-availability-new
to compiler flags for Apple platforms #100384