This was raised in D52660. Today, libc++ recognizes at least 3 different ABI versions: v1, v2 (and above) and unstable, see https://github.com/llvm-mirror/libcxx/blob/master/include/__config#L66.
There is V1.
There is V2 and unstable. Today, those are the same.
There are several questions that were raised in that review that I’d like to get clarity on:
- Is there a plan to eventually stabilize v2 and introduce v3 (and above) as the unstable version or is v2 going to be unstable forever?
We (the libc++ team) have no plans to do so - because we never ship a libc++.
(We do have a mechanism to do so, but no plans)
The decision of what ABI to support is made by the people who ship libc++
- What are the guarantees for v2? I understand that this ABI can still change, but I’m interested in testing and stability, shall we expect that v2 receives the same amount of coverage and that bugs specific to v2 will get resolved with the same priority as bugs specific to v1?
Since the ABI version is part of the generated __config header, it’s a vendor rather than per-target option which means it affects all targets that use libc++ headers from the toolchain.
This is fine for us since we always link libc++ statically on host and we don’t have any plans to guarantee a stable C++ ABI on the target. The improvements seem to be worth using v2 over v1, but I’d like to better understand what the plans and guarantees are before committing to it.
This is not a choice that we (the libc++ maintainers) can make.
This is up to the people who build libc++.
Apple, for example, ships V1 on Mac OS X (i386 and x86_64), but offers a different ABI on ARM64.
(at the very least, they define
I have no idea what Android does.
Since you link libc++ statically, and have no abi concerns, I would use
This contains changes/improvements/bug fixes that we were unable to ship generally, because of ABI concerns.
Hope this helps.