[libcxx-commits] [libcxx] [libcxxabi] [libc++] Fix broken configuration system-libcxxabi on Apple (PR #110920)

[via libcxx-commits]

h-vetinari wrote:

So I'm trying this in https://github.com/conda-forge/libcxx-feedstock/pull/177, and I'm getting
```
+ llvm-nm $PREFIX/lib/libc++.1.dylib
dyld[11925]: Symbol not found: __ZTVN10__cxxabiv117__class_type_infoE
  Referenced from: <5D911EBA-4AB2-3C92-B9D5-977E209853B5> $PREFIX/bin/llvm-nm-18
  Expected in:     <E516FB63-086F-3A12-B5C7-A0FD4F00B3EA> $PREFIX/lib/libc++.1.0.dylib
compile_test.sh: line 12: 11925 Abort trap: 6           llvm-nm $PREFIX/lib/libc++.1.dylib
```

It's plausible/possible that this is a behavioural difference between our current workaround to depend on the system libcxxabi and doing it "properly". In particular, the `llvm-nm` binary that's in use for testing _after_ successful compilation was built[^1] against the "current world" of our libcxx handling, which does [roughly](https://github.com/conda-forge/libcxx-feedstock/blob/main/recipe/build.sh):
```bash
ninja -C build cxx cxxabi unwind
ninja -C build install-cxx install-cxxabi install-unwind
$INSTALL_NAME_TOOL -change "@rpath/libc++abi.1.dylib" "/usr/lib/libc++abi.dylib" $PREFIX/lib/libc++.1.0.dylib
```
I'm aware that this is fragile (and we do carry a patch for systems before macOS 12 due to ABI differences), but it's what we had to move to, because the system libcxxabi gets picked up in some situations (e.g. from CPython, see README [here](https://github.com/conda-forge/libcxx-testing-feedstock/tree/main/recipe/pybind11_exception_rtti_test)).

[^1]: For various reasons we do rely on shared libraries wherever possible. Meaning that `llvm-nm` itself depends on `libc++`, and when we build a new `libc++`, the existing builds of `llvm-nm` should keep working seamlessly if their `libc++` gets updated underneath them. This is where we're now falling over, i.e. it'd be a kind of ABI break for us -- assuming this isn't due to a bug somehow.

IOW, it's conceivable to me that (re)building everything in a `-DLIBCXX_CXX_ABI=system-libcxxabi` world would work out fine. For now though I'm not sure how a cxxabi symbol ends up in `libc++.1.0.dylib` (using the script above) but we'd have to fix that somehow to ensure stuff doesn't break if/when we switch.

CC @isuruf

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