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

[via libcxx-commits]

h-vetinari wrote:

Sorry for the delayed response! I was planning to get to this but not fast enough apparently 😅 

> 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.

Not sure I understand 100%, but in our case the system ABI has a clear lower bound and we know it at build-time (currently 10.13 on osx-64, 11.0 on osx-arm64).

> 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.

This might be naïve, but can't we just start by relying on the availability of symbols from the lower-bound system ABI? This is effectively what we're doing already. If we're building on 10.13, we require (through our package metadata that drives whether an artefact can be installed) that the resulting package can only be installed on macOS>=10.13. That has worked for a long time already, and didn't need a full mapping.

> How was `$PREFIX/lib/libc++.1.0.dylib` built?

I had pasted the essence of the build script above; here's the [link](https://github.com/conda-forge/libcxx-feedstock/blob/main/recipe/build.sh) to the full thing again.

> 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`.

That sounds very plausible, but it needs to be happening essentially by default, because I'm not actively choosing to re-export the libcxxabi symbols (I would have wanted to avoid that, had I known).

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