Upstream removal of _LIBCPP_DISABLE_AVAILABILITY; dealing with Apple SDK vs our libcxx

[h-vetinari]

Upstream removed _LIBCPP_DISABLE_AVAILABILITY in llvm/llvm-project#112952 for the upcoming LLVM v20; this removes the mechanism we've been telling feedstocks to use for a long time. I had tagged a few core members then already, but perhaps this got lost in the flood of notifications. After some discussion, the conclusion the lead libc++ maintainer arrived at was:

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.

This to me sounds very reasonable (and we should do this for all our supported clang versions when we release libcxx v20), but if someone sees something wrong with this, please let me know.

CC @conda-forge/core

[h-vetinari]

Thoughts? @xhochy @isuruf @beckermr

[isuruf]

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.

This is not true. You can easily check where we are getting the C++ Standard Library headers from by running clang++ -v test.cpp

. If you want to use the SDK but provide your own C++ Standard Library, you should do this:

Given above, this is unnecessary.

[h-vetinari]

I don't have a mac so I cannot try this (well, except in a CI job somewhere)...

Given above, this is unnecessary.

Our docs tell users to set a symbols (_LIBCPP_DISABLE_AVAILABILITY) that won't be in the next release anymore. Since we're using exclusively our own headers (per your "this is not true"), what is the way forward there?

Presumably the availability mark-ups would start firing again as soon as someone uses clangxx 20 (the recent separation of the libcxx headers from the library gives us about a year more breathing room at least; before, it would have triggered already as soon as we published libcxx 20).