Hilariously, Apple actually considers the shift from C++98 to C++11 something that required an operating system upgrade (they purposefully shipped an ancient version of libstdc++ while disingenuously doing comparisons against only what they shipped, not what had come from upstream, for as long as they could until libc++ was reasonable, which debuted on macOS 10.7--where I will note it was horribly broken due to an LLVM optimizer bug in the specific clang build they used to compile it, so really it wasn't available until macOS 10.8--and as Apple does not believe in static linking, their SDK doesn't have a way to work around this; of course, you can, and I did--by getting the code for libc++, modifying it to use an underlying libstdc++ as the moral equivalent of libc++abi, and statically linking that, which worked great and is frankly what Apple should have done themselves during the transition period :/--it is notable that Apple didn't want people to: they really do mentally model that as an operating system upgrade, which to me is an amazing demonstration of how little they understand of the power and potential of decoupled toolchains).
> Apple does not believe in static linking, their SDK doesn't have a way to work around this
Apple isn’t alone this regard; as far as I can tell Windows does this too because they don’t commit to a stable syscall interface like Linux does. That being said, you may find Apple’s official stance on statically linking your binaries amusing: https://developer.apple.com/library/archive/qa/qa1118/_index...
In general, Apple links a lot of things to their OS releases: while their toolchains are distributed separately they’re practically tied to one or two major OSes unless you engage in hacks to make them continue working. And the languages which they exercise significant control over (namely Swift and Objective-C) are often tied to OS versions.
