In 6a884a9, I synchronized the export list of libc++abi to the export list of libc++. From the linker’s perspective, this caused some newly re-exported symbols to be encoded as provided by libc++.dylib instead of libc++abi.dylib. That behaviour was new in LLVM 19.
However, we later found out that this could be problematic when back-deploying. Indeed, this change meant that the linker would encode an undefined reference to be fulfilled by libc++.dylib, but when backdeploying against an older system, that symbol might only be available in libc++abi.dylib.
Most of the symbols that started being re-exported after 6a884a9 turn out to be implementation details of libc++abi, so nobody depends on them and this back-deployment issue is inconsequential. However, a few symbols did create a real problem, in particular with code that uses sanitizers since there is a layering violation in the way some sanitizers are implemented leading them to the use of these libc++abi implementation details.
Hence, we recently reverted the re-exportation of these problematic symbols from libc++.dylib in release/19.x: [libc++] Avoid re-exporting a few specific symbols from libc++abi (#109054) by llvmbot · Pull Request #110677 · llvm/llvm-project · GitHub. That change will land in LLVM 19.1.2.
The net effect is that symbols are being removed from libc++.dylib going from any previous LLVM 19 release to LLVM 19.1.2 and later. This only affects libc++.dylib when used on Apple platforms, which is the only platform where we re-export libc++abi.dylib symbols.