[libcxx-commits] [libcxx] [libcxxabi] [libc++] Avoid re-exporting a few specific symbols from libc++abi (PR #109054)

[Louis Dionne via libcxx-commits]

ldionne wrote:

> Hi, since we are wrapping up this next release we are very strict with the fixes we pick at this point. Can you please respond to the following questions to help me understand if this has to be included in the final release or not.

100% understood.

> 
> Is this PR a fix for a regression or a critical issue?

Yes. I basically introduced an unintended ABI break in 6a884a9aef397f76178b141d789efadf280f2c3f, it just happened that the ABI break was subtle enough not to cause any issues outside of our internal release testing.

> 
> What is the risk of accepting this into the release branch?

Code compiled against LLVM 19.1 (released with these symbols in `libc++.dylib`) could fail with unresolved symbols when running against LLVM 19.2 (which would contain this patch), since this is effectively removing symbols from `libc++.dylib`. But those symbols should never have been there in the first place (well, not until we do some cleanup anyways).

> 
> What is the risk of NOT accepting this into the release branch?

Code linking against LLVM 19.1's `libc++.dylib` may fail with undefined references when run on an older `libc++.dylib`. That basically breaks the "backdeployment" use case, which is important on Apple platforms. FWIW, we're taking this fix in our internal release regardless of whether it makes it upstream because we can't publish a release without this fix. I think it would be better to keep both in sync but I'll leave it to you to decide based on the above.

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