[libcxx-dev] Clarification around ABI version
mclow.lists at gmail.com
Mon Oct 1 21:23:22 PDT 2018
On Mon, Oct 1, 2018 at 8:00 PM Petr Hosek via libcxx-dev <
libcxx-dev at lists.llvm.org> wrote:
> ---------- Forwarded message ----------
> From: Petr Hosek <phosek at chromium.org>
> To: libcxx-dev at lists.llvm.org
> Date: Mon, 1 Oct 2018 20:00:09 -0700
> Subject: Clarification around ABI version
> This was raised in D52660. Today, libc++ recognizes at least 3 different
> ABI versions: v1, v2 (and above) and unstable, see
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:
> 1. 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
(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++
> 2. 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 `_LIBCPP_ABI_ALTERNATE_STRING_LAYOUT`)
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the libcxx-dev