bpo-43052: Make dyld search work with SYSTEM_VERSION_COMPAT=1

[isuruf]

In macOS Big Sur, if the executable was compiled with MACOSX_DEPLOYMENT_TARGET=10.15
or below, then SYSTEM_VERSION_COMPAT=1 is the default which means that Big Sur
reports itself as 10.16 which means that __builtin_available(macOS 11.0) will not be triggered.

This can be observed by using the python 3.9.1 universal2 installer and using it on
x86_64 Big Sur or with Rossetta 2 on arm64 Big Sur. (Not an issue with native arm64
as that part is compiled with MACOSX_DEPLOYMENT_TARGET=11.0)

cc @ronaldoussoren

https://bugs.python.org/issue43052

[isuruf]

Original issue is that the following returned None.
SYSTEM_VERSION_COMPAT=1 arch -x86_64 /usr/local/bin/python3 -c "from ctypes.util import find_library; print(find_library('AppKit'))"

[ned-deily]

Thank you for the PR. Please open an issue for this on bugs.python.org and add the issue number to the PR as described in the Python Developers Guide.

[ronaldoussoren]

Is there documentation how this works? In particular, documentation that shed a light on what will happen once macOS 12 is released.

There are other checks for macOS 11 using __builtin_available, and there may be similar checks for macOS 12 later on. I wonder how that will work SYSTEM_VERSION_COMPAT=1.

[isuruf]

I don't know. I only saw https://eclecticlight.co/2020/08/13/macos-version-numbering-isnt-so-simple/

Consider the following program A,

int main() {
  if (__builtin_available(macos 11.0)) {
    return 1;
  } else {
    return 0;
  }
}

and program B,

int main() {
  if (__builtin_available(macos 10.16)) {
    return 1;
  } else {
    return 0;
  }
}

compile A with clang -arch x86_64 -mmacosx-version-min=11.0 and run it, it will return 1.
compile A with clang -arch x86_64 -mmacosx-version-min=10.9 and run it, it will return 0.
compile B with clang -arch x86_64 -mmacosx-version-min=11.0 and run it, it will return 1.
compile B with clang -arch x86_64 -mmacosx-version-min=10.9 and run it, it will return 1.

For macOS 12, I have no idea how it will work. (probably, it'll be 10.17, but that's pure speculation on my part)

[ned-deily]

See my comment about this on the bug tracker.

[github-actions]

This PR is stale because it has been open for 30 days with no activity.

[ned-deily]

It hasn't been established yet that this change is needed. See the discussion here on the PR and on the bug tracker. Without further justification, I would suggest we close the PR.

[bedevere-bot]

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 I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

[github-actions]

This PR is stale because it has been open for 30 days with no activity.

[ronaldoussoren]

It hasn't been established yet that this change is needed. See the discussion here on the PR and on the bug tracker. Without further justification, I would suggest we close the PR.

I agree. This only affects users running with "SYSTEM_VERSION_COMPAT" set in the environment, find_library works correctly otherwise.