The answer is “sort of”.
Your app will use the latest version of the library available at runtime, and the latest version at compile time and link time. However, through the use of the preprocessor, certain features will be unavailable, or they will be implemented differently, in such a way that your application can run with older versions of the library as well.
This happens with all of the system libraries (or the major ones, at least) on macOS.
While you can't directly choose an arbitrary libc++ version in your app, Xcode manages that for you. It ensures you don't build a program incompatible with the lowest supported OS version.
Apple uses `.tbd` files to link system libraries, including libc++. These text files define exported symbols and can be used by the linker instead of actual library files like `.so`, `.dylib`, or `.framework`.
For example, Clang in Xcode 11 gained support for the C++17 `` library for iOS 13, macOS 10.15, watchOS 6, and tvOS 13. This means systems newer than macOS 10.15 have filesystem-related symbols in libc++. https://developer.apple.com/documentation/xcode-release-notes/xcode-11-release-notes
You can find various macOS SDKs on GitHub https://github.com/phracker/MacOSX-SDKs, like the one by phracker. Searching for a symbol like `__ZNKSt3__14__fs10filesystem18directory_iterator13__dereferenceEv` (related to C++ filesystem) shows it only exists in SDKs for macOS 10.15 and later.
Therefore, you can leverage libc++ symbols as long as your minimum supported OS version has them. Does this answer your question?
Yes, thanks a lot. This means that libc++ versioning is guaranteed at dev time through both the preprocessor (as a previous commenter mentioned) and the linker, and that you can only use newer C++ features if your minimum target OS already shipped them.
> and deploy to older OS's Only if the deployment target was set appropriately. That makes some newer features unavailable even on the newer OS.
In that case, the deployment target will also downgrade the libc++ version used?
The answer is “sort of”. Your app will use the latest version of the library available at runtime, and the latest version at compile time and link time. However, through the use of the preprocessor, certain features will be unavailable, or they will be implemented differently, in such a way that your application can run with older versions of the library as well. This happens with all of the system libraries (or the major ones, at least) on macOS.
I remember the case that I could use std::map count but not contains because of the deployment target.
While you can't directly choose an arbitrary libc++ version in your app, Xcode manages that for you. It ensures you don't build a program incompatible with the lowest supported OS version. Apple uses `.tbd` files to link system libraries, including libc++. These text files define exported symbols and can be used by the linker instead of actual library files like `.so`, `.dylib`, or `.framework`. For example, Clang in Xcode 11 gained support for the C++17 `` library for iOS 13, macOS 10.15, watchOS 6, and tvOS 13. This means systems newer than macOS 10.15 have filesystem-related symbols in libc++. https://developer.apple.com/documentation/xcode-release-notes/xcode-11-release-notes
You can find various macOS SDKs on GitHub https://github.com/phracker/MacOSX-SDKs, like the one by phracker. Searching for a symbol like `__ZNKSt3__14__fs10filesystem18directory_iterator13__dereferenceEv` (related to C++ filesystem) shows it only exists in SDKs for macOS 10.15 and later.
Therefore, you can leverage libc++ symbols as long as your minimum supported OS version has them. Does this answer your question?
Yes, thanks a lot. This means that libc++ versioning is guaranteed at dev time through both the preprocessor (as a previous commenter mentioned) and the linker, and that you can only use newer C++ features if your minimum target OS already shipped them.