[3.8] [3.7] `test_mkfifo_dir_fd` triggers segfaults on macOS CI

[pradyunsg]

A PR upgrading pip's wheel on 3.8 (which shouldn't really affect the test_mkfifo_dir_fd) triggered a segfault on the macOS test run.

https://github.com/python/cpython/actions/runs/4269978257/jobs/7433511913#step:6:651

Looking through the issue tracker, I don't see that failure mode reported as is and I'm noting it here mostly since I'm not sure if it's in any way related to this ongoing thing or if it should be a separate issue. It doesn't seem like it is, but I've not followed the failure discussions here closely to know for sure. 😅

Originally posted by @pradyunsg in #101981 (comment)

We've also seen this happen on certain other runs as well since, including a re-run on the aforementioned PR.

Linked PRs

• [3.8] GH-102306 Avoid GHA CI macOS test_posix failure by using the appropriate macOS SDK #102307
• [3.7] GH-102306 Avoid GHA CI macOS test_posix failure by using the appropriate macOS SDK. #102427

[ned-deily]

This is the problem identified in #97897. Undoubtedly, the Github image is using macOS 12.6.x but the default SDK in the installed Command Line Tools is linked to a macOS 13 SDK. We did not backport the change to 3.8 because we don't support full macOS "weaklinking" on Python 3.8 but it can be a problem in edge-cases like this (Apple forces a problem by introducing the use of a new release's SDK on the previous system). We should be able to avoid the problem by backporting some code, by explicitly building with a MacOSX12.sdk, or by changing the CI to build with macOS 13 Ventura. (Note this is only a problem when building on macOS 12 with a macOS 13 SDK as explained in the linked issue.) It's @ambv's call.

[ned-deily]

As a proof-of-concept, #102307 shows that just forcing the SDK avoids the issue.

[ned-deily]

This is also an issue for 3.7.x; #102427 is a backport.