On Thu, 13 Feb 2014 10:11:27 +0000 David Chisnall <thera...@freebsd.org> wrote:
> On 13 Feb 2014, at 01:04, Alexander Kabaev <kab...@gmail.com> wrote: > > > The refusal to use tools that are there precisely to help to help > > with the binary compatibility in favor of mindless library bumps is > > just sad. > > Perhaps you could share with the class. What is the correct way of > solving this problem? > > For those just joining the discussion, the issue is that std::pair > was originally declared with an explicit constructor and should have > an implicit constructor, which has a different calling convention. > This means that we can't share the two std::pair implementations > across libraries, because they will try to call the constructor with > the wrong arguments. Because of templates and C++ name mangling, > this ends up being propagated into most libraries that link against > libc++, and calling from one with the old definition to one with the > new definition end up causing segfaults (if we're lucky - I think the > symptom that we're seeing is actually dereferencing a junk value in a > register, so it may cause random memory writes, but I'd have to check > the ABI). > > Given that neither redeclaring the new std::pair in a new namespace, > nor exporting both constructor symbols using symbol versioning (the > two approaches that we've already discussed) will work, what are the > tools that apparently we're refusing to use that will work? > > David OK, I think the confusion has started because reported to this as an ABI incompatibility within libc++ itself, which is not the case here. When calling convention of a public symbol changes, one can put the old definition under the compatibility version that is only available for runtime binding, this allowing old binaries to work and that is what I was referring to. Unfortunately, that won't work in this case because libc++ proper does NOT export any symbols with 'pair' in them, so it is not affected by the ABI breakage itself. What libc++ developers did is they exported ABI breakage into every binary that was compiled with different revisions on libc++ _header_ files, not linked with the library proper. Using the library major version as a circumstantial evidence indicating header versions binary was compiled with might work then, though is not 100% reliable. Theoretically one can compile the binary that uses std::pair template but does not record libc++ as the runtime dependency. Still, that is better than nothing. ABI stability and C++ apparently should be mentioned in the same sentence, unless there's also a 'pipe dream' in it. And you do deserve an apology for my remark. -- Alexander Kabaev
signature.asc
Description: PGP signature
