[macOS] Link __availability_version_check

[cbracken]

Links in an implementation of _availability_version_check on macOS.
This is required due to an upstream compiler builtin (runtime) change
that marked this function as weakly-linked via __attribute__((weak import))
As such, no linking failure occurs when the function is unavailable at
link time. Since the symbol is no longer linked in, App Store review
blocks publishing due to relying on a private symbol.

By providing an implementation, the linker picks up our implementation,
which looks up symbol in question at runtime (via dlsym) on the first
invocation, caches it for later invocations, then invokes it. This is,
in fact, precisely what the original clang builtin implementation did.

Upstream clang change: https://reviews.llvm.org/D150397

Issue: flutter/flutter#133777

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene wiki page, which explains my responsibilities.
• I read and followed the Flutter Style Guide and the C++, Objective-C, Java style guides.
• I listed at least one issue that this PR fixes in the description above.
• I added new tests to check the change I am making or feature I am adding, or Hixie said the PR is test-exempt. See testing the engine for instructions on writing and running engine tests.
• I updated/added relevant documentation (doc comments with ///).
• I signed the CLA.
• All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

[zanderso]

Thanks!

[Hixie]

Is "Calling dlsym with RTLD_DEFAULT can be very slow as all images in the process are searched for the symbol." (the reason for the upstream change) a concern for Flutter?

[cbracken]

Is "Calling dlsym with RTLD_DEFAULT can be very slow as all images in the process are searched for the symbol." (the reason for the upstream change) a concern for Flutter?

This is a single lookup that we cache on first call and never do again so the impact is low. Agreed that ideally we wouldn't even do that one lookup, but it is identical to the behaviour that we had all along -- i.e. not a regression, though not an improvement.

An alternative might be to go back to dealing with two clang toolchains and use Apple's Xcode toolchain rather than our own.

[zanderso]

An alternative might be to go back to dealing with two clang toolchains and use Apple's Xcode toolchain rather than our own.

IMO, that approach would cause an unacceptable regression in CI build times.

[Hixie]

Oh I'm definitely not saying we should have two toolchains. The implication of the upstream comment is that we could save some time on startup if we avoided the lookup. Hopefully we'll get that when we remove this workaround when Xcode updates (i.e. when everyone else does).