[libcxx-commits] [libcxx] [libc++] Encode the standard version in the ABI tag (PR #218527)

[Nikolas Klauser via libcxx-commits]

philnik777 wrote:

> > Thanks for the heads up @mstorsjo . I think the right fix here is to avoid exporting symbols with ABI tags from the dylib, which the author of #222081 seems to agree with. Let's pursue a fix in that direction. If we need immediate relief, I would suggest dropping the standard version from the ABI tag on Mingw (only) as a temporary measure, and bringing it back as soon as the underlying export issue is resolved.
> 
> Yeah it's not super urgent - currently it only annoys me by alerting me with a broken weekly test round. :-) The ABI tag in the DLL interface has appeared after the last release, so let's make sure we get it sorted out before the next release.
> 
> The proper precaution going forward would be to set up ABI lists for the mingw build too - I remember discussing this with someone at some point, but I haven't gotten around into looking in to setting it up. Even if we might not consider the libc++ mingw ABI 100% stable and can tolerate smaller ABI breaks if they are motivated, an ABI lists file for the target would help catching unexpected symbols in the DLL interface. (The issue the last time this was discussed was also a case where an ABI tag had snuck into the DLL interface.)

I was actually about to ask whether we can set such a thing up. As you say, even if the ABI isn't stable, it's still good to be conscious of a change in ABI. That is, I'd also be happy if we had ABI lists for the MSVC ABI, purely for the purpose of being informed if the ABI unexpectedly changes. Especially given that we don't know the MSVC ABI nearly as well as the Itanium ABI (I assume that's the case for most libc++ contributors at least).

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