svn commit: r261283 - in head: contrib/libc++ contrib/libc++/include contrib/libc++/include/experimental contrib/libc++/include/ext contrib/libc++/src etc/mtree lib/libc++ sys/sys tools/build/mk

[Alexander Kabaev]

On Mon, 3 Feb 2014 18:54:46 +0000
David Chisnall <theraven at FreeBSD.org> wrote:

> On 3 Feb 2014, at 18:32, Alexander Kabaev <kabaev at gmail.com> wrote:
> 
> > More than likely. It does appear libc++ does not go through same
> > pains to maintain ABI stable as libstdc++ does. The lack of all and
> > any symbol versions in shared library binary strongly suggests that
> > not only they do not bother with ABI stability, they simply can't
> > enforce it at the moment even if they wanted to.
> 
> libc++ aims to provide a stable ABI, however it does so in a manner
> that is intended to integrate with the source language, rather than
> by applying linker hacks post facto (which is very hard to do write
> with C++).  Every std:: class in libc++ is implemented inside a
> version namespace inside std, and then imported into std:: in the
> header.  ABI-breaking classes should be inside a new version
> namespace.
> 
> If you have examples where the ABI was not accidentally changed, then
> please report them as bugs and we will try to fix them.  If you just
> have unfounded supposition, then it is not helpful to the discussion.
> 
> David

At the very least, new library did remove
_ZNKSt3__111__libcpp_db12__comparableEPKvS2_ which was public before.
Your definition of ABI stability might be different from mine, but in
my book that counts as a backward compatibility breakage. And even if
that symbol was not supposed to be lined to by anyone, it should not
have been exported in the first place.


-- 
Alexander Kabaev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-src-all/attachments/20140203/c6d3e4a7/attachment.sig>