This (I believe) resolves the last of the blockers for switching us away from cctools and instead using out-of-the-box llvm and lld for building Darwin binaries.
For now, we continue building with a pre-packaged llvm and cctools, but after this PR the clang+lld combo should just work for anyone trying it. Additionally after this PR, the new runtime fixup_chains behavior will be in-use, as ld64 uses it as well.
The commits may seem unrelated, so in detail:
lld (llvm’s linker) has been a work-in-progress for Darwin for years. Recently though, it has gained nearly all of the features we require. The last missing feature from ld64, -Wl,-bind_at_load, is not implemented in lld; as far as I can tell lazy loading has conceptually been replaced by fixup chains.
So that means we don’t need ld64’s bind_at_load as long as lld can handle -Wl,-fixup_chains (which it can). I’ve added it to our configure as a linker option mostly so that we can see it in the logs; it’s default-on as long as the minimum version is >11.0.
About that: the runtime functionality required for -Wl,-fixup_chains requires macOS >=11.0. Hence the commit that bumps the minimum version. Our current min runtime of 10.15 has been unsupported since September 2022, so I don’t expect this bump to be controversial.
Lastly, with the minimum runtime version bumped to 11.0, our current version of pre-compiled clang we use for macOS is too old to understand -mmacosx-version-min=11.0 because it expects =10.x. So I’ve made the smallest possible bump (from 10.0.1 to 11.1.0) to a version that understands. This bump is arbitrary and unfortunate, but likely to be short-lived as we may end up replacing it with llvm+lld for v26 anyway. I’ve held off on bumping the SDK as I think that makes sense to do as part of the lld switch instead.
