On Mon, 3 Feb 2014 18:54:46 +0000 David Chisnall <thera...@freebsd.org> wrote:
> On 3 Feb 2014, at 18:32, Alexander Kabaev <kab...@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
signature.asc
Description: PGP signature
