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

[Louis Dionne via libcxx-commits]

ldionne wrote:

> So I'm trying this in [conda-forge/libcxx-feedstock#177](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
> ```


How was `$PREFIX/lib/libc++.1.0.dylib` built? Presumably it was built in a way that it advertised the presence of symbol `__ZTVN10__cxxabiv117__class_type_infoE`, which is the only way the linker would have encoded that dependency in `llvm-nm-18`.

------------------

Another thing you could try on the side is to re-export `libc++abi.dylib` itself from `libc++.dylib` instead of the list of its symbols. There's a fundamental problem with re-exporting the list of libc++abi symbols that otherwise can't be solved when building against the system libc++abi: we don't know what version of the system libc++abi you're building against, so we don't know the list of symbols. And even if we knew the version of libc++abi you're building against, we'd have to maintain a mapping of every historical `libc++abi.dylib` that was shipped to the list of symbols it contained in order to make that happen.

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