Consider adding -Werror=unguarded-availability-new to compiler flags for Apple platforms

[indygreg]

Feature or enhancement

Runtime crashes like #97897 could be prevented by turning clang's unguaded-availability-new warning into a fatal compile error. This can be done by adding -Werror=unguarded-availability-new to 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. -Werror upconverts 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 mkfifoat and mknodat. (Although this may be an oddity from python-build-standalone and not a CPython bug.)

cc @ned-deily

[indygreg]

Ignore my comment about 3.8. 3.8 doesn't have properly weak linking support at all (at least not in posixmodule.c). The mkfifoat and mknodat errors 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.

[ronaldoussoren]

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.