[libcxx-commits] [libcxx] [libc++] Remove _LIBCPP_DISABLE_AVAILABILITY macro (PR #112952)

[Louis Dionne via libcxx-commits]

================
@@ -85,6 +85,9 @@ Deprecations and Removals
 - The function ``__libcpp_verbose_abort()`` is now ``noexcept``, to match ``std::terminate()``. (The combination of
   ``noexcept`` and ``[[noreturn]]`` has special significance for function effects analysis.)
 
+- The ``_LIBCPP_DISABLE_AVAILABILITY`` macro that was used to force-disable availability markup has now been removed.
+  Whether availability markup is used by the library is now solely controlled at configuration-time.
----------------
ldionne wrote:

> Because our users are necessarily installing a full environment (where we control dependencies and distribution), we can rely on the fact that we can always ship an up-to-date `libc++.dylib`. We also use up-to-date the libc++ headers when compiling things, but we still need to use point to _some_ Apple SDK (for which older versions are available, e.g. from https://github.com/phracker/MacOSX-SDKs or https://github.com/alexey-lysiuk/macos-sdk), and we're generally on a 10.13 baseline for now.

Ok, this makes sense. I assume you're doing something like `-isysroot <PATH-TO-OLDER-SDK>`, which means you're getting the C library headers (and other system headers) from that SDK. However, as a side effect, you're also getting the older C++ Standard Library headers located in `SDKROOT/usr/include/c++/v1`, and those have undesirable availability markup in them.

You don't want that. In particular, you really really don't want to be using Apple "system libc++" headers from the SDK but linking against your own self-built `libc++.a` or `libc++.dylib`. That's brittle and can break badly at any point. Those are two distinct libraries and they only happen to share the same name and the same symbol names for the most part, but pedantically you're using entirely incompatible headers and built library. If you want to use the SDK but provide your own C++ Standard Library, you should do this:

```
-isysroot <SDK>
-nostdinc++ -isystem <path-to-your-libcxx-headers>
-nostdlib++ -L <path-to-your-libcxx-dylib> -l c++
```

That way, you're overriding both the library and the header search paths to make sure you find consistent ones. I think this is where @philnik777 was going above. Please let me know if this makes sense to you.

> Finally, where we're aware of it, we do patch relevant ABI differences for older macOS system libs, compare e.g. [this patch](https://github.com/conda-forge/libcxx-feedstock/blob/main/recipe/patches/0001-Fix-ABI-compatibility-with-system.patch) to realign a struct, resp. the related [discussion](https://discourse.llvm.org/t/shipping-custom-libc-on-macos/58606) (I think the original email [thread](https://lists.llvm.org/pipermail/libcxx-dev/2021-July/001172.html) got split a bit by the discourse migration). This isn't great, but given that the system ABI isn't 100% stable, this is +/- the best we can do under the given constraints.

We do strive to be 100% backwards compatible. I added a reply to the Discourse thread explaining what I think is happening here and why I don't think that's libc++'s "fault": https://discourse.llvm.org/t/shipping-custom-libc-on-macos/58606/7. TLDR, it looks to me like some programs end up with multiple copies of libc++ in them, which is an ODR violation. Reordering these lines as you do in the patch simply makes that ODR violation be benign and inconsequential, but doesn't technically solve the problem.

https://github.com/llvm/llvm-project/pull/112952