Repository navigation
Consider adding -Werror=unguarded-availability-new to compiler flags for Apple platforms #100384
Description
Activity
Ignore my comment about 3.8. 3.8 doesn't have properly weak linking support at all (at least not in
posixmodule.c). Themkfifoatandmknodaterrors were just clang catching these symbols falling through a gap in python-build-standalone's build system, which attempts to disable all optional symbols on 3.8 to work around the lack of weak referencing. I think this demonstrates the value of-Werror=unguarded-availability-new, as without this, I probably would have shipped binaries that segfault at runtime.3.9 and later should have weak linking support in posixmodule, this was introduced while working on support for arm64 and Universal 2 binaries. That said, newer SDKs can introduce new APIs that require changes to that.
Copying over some of my commentary from #128135
Here's an initial patch 36c7da4
- I'm not sure if we should be using
unguarded-availabilityorunguarded-availability-new? - This flag is
clang-only, will this help prevent regressions upstream or just avoid shipping bad code downstream? - In
-Werror=unguarded-availability-newin sysconfig prevents building ofwatchdogastral-sh/python-build-standalone#210, users reported if this is present in theCFLAGSinsysconfigit is used to build extension modules in some packages which causes failures. Would this be a problem here too? Is there existing infrastructure to deal with this problem?
- I'm not sure if we should be using
Instead of
CFLAGS, try adding this toCFLAGS_NODIST. "CFLAGS_NODISTis used for building the interpreter and stdlib C extensions. Use it when a compiler flag should not be part ofCFLAGSonce Python is installed."Ah cool, thanks @ned-deily. I was hoping there was something like that.
Do you have any other concerns before I post the patch as a pull request?
I think my most important open question is
This flag is
clang-only, will this help prevent regressions upstream or just avoid shipping bad code downstream?Is
clangbeing used in CI?The Xcode C toolchain is clang. There are an extremely small number of people not using clang when targeting Apple platforms. I'm pretty sure CPython's build system implicitly requires clang for Apple targets.
Reacted by Zanie BlueWe use clang on build bots sanitizers (UBSan, TSan and ASan) so yes we use
clang. And for the JIT as well since this requires LLVM.What we could do is integrate this new flag as part of our CI without necessarily making it part of the
configurescript. At least it could help without affecting local configurations? cc @hugovkLike with this tooling?
Reacted by Bénédikt TranI think the concern about it affecting users is addressed by using
CFLAGS_NODIST, is there a different concern you have that makes this better as a warning than an error?I'm not sure if we should be using unguarded-availability or unguarded-availability-new?
If I understand the implications correctly, I think we should stick with
unguarded-availabilityuntil there is a demonstrated need to restrict tounguarded-availability-new.Also we specifically now check and report on supported platform / compiler combinations (see
AC_MSG_CHECKING([for PEP 11 support tier])inconfigure.ac) which for macOS isclangfor tier 1 support. That said, we should be careful to not deliberately breakgccbuilds; presumably theAX_CHECK_COMPILE_FLAG([-Wunguarded-availability] ...test in the patch should take care of that.- added a commit that references this issue
on Oct 2, 2026
Feature or enhancement
Runtime crashes like #97897 could be prevented by turning clang's
unguaded-availability-newwarning into a fatal compile error. This can be done by adding-Werror=unguarded-availability-newto compiler flags.Essentially what this warning does is cross reference undefined symbols against symbols defined in the targeted Apple SDK. If it sees a symbol introduced in a newer SDK version and that symbol isn't weakly referenced/linked, you get a warning.
-Werrorupconverts it to a fatal compiler error.If you add this flag to release builds, the compiler prevents you from shipping binaries that ship unguarded symbol usage for targeted SDK versions. i.e. it prevents run-time crashes when binaries run on older Apple OS versions.
If you enable this setting today, you may find the 3.8 branch isn't properly gating use of
mkfifoatandmknodat. (Although this may be an oddity from python-build-standalone and not a CPython bug.)cc @ned-deily
The advantages of having this additional warning is to catch regressions such as:
ptsname_ris not checked at runtime on macOS #123797Linked PRs
unguarded-availabilityin Darwin builds #128155