On Sat, Mar 24, 2012 at 11:54:21AM -0400, Alexander Kabaev wrote: > On Fri, 23 Mar 2012 23:39:44 +0000 > David Chisnall <thera...@freebsd.org> wrote: > > > On 23 Mar 2012, at 21:10, Konstantin Belousov wrote: > > > > > The patch just committed made the base-shipped library incompatible > > > with the ports and manual libstdc++ builds. > > > > To clarify - the one shipped in the base system has been incompatible > > with the one in ports since late 2007... > > > That says something about the extend of the breakage, does it not? > > > In future, however, we will want libstdc++ in ports to be using the > > system ABI library (e.g. libcxxrt) so that it can be linked with > > libraries using the system C++ stack, so the layout of std::type_info > > in its headers doesn't matter too much because it won't be used. > > > > > I think it is wiser to > > > not 'undo the undo', and instead start living with the > > > upstream-approved ABI. For symvered library, it does not make any > > > difference if you break it in 10.0 or 9.1. > > > > Not true. The vtable layout can not be symbol versioned > > effectively. The std::type_info class is required by the ABI to > > exist (and is in libsupc++ / libcxxrt, so is independent of our STL > > implementation, either libstdc++ or libc++). Users expect to be able > > to cast > > > > > Also, I think that consumers that depend of the ABI of > > > std::typeinfo can be hacked to understand the layout of vtable. > > > > Supporting both layouts is not really tenable. We need to do one of > > the following: > > > > - Say 'we are going to break this now!' and force people to recompile > > libsupc++, libcxxrt, and libobjc2. > > - Keep the layout that we currently ship and patch <typeinfo> in > > ports. > > > > I don't mind which of these we do since I'm not the one that has to > > do the work in ensuring compatibility with ports but it will need to > > pick one and then stick to it... > > > > > I doubt that there are > > > many users that utilize typeinfo. > > > > Yes, to my knowledge there are three, and two of them are me :-( > > > > I will support the switch to 'default' ABI used upstream, provided > David is onboard. The breakage is very limited at the moment and > can only grow over time, so will grow the pain, while we insist on being > diverged from GCC. We might as well bite the bullet and live through > this at the cost of 9.1 release errata that only affects libobjc2. Right, this was my point, and you seems to agree with me: better to make a switch back to the upstream ABI sooner (9.1) rather then later (10.0).
pgp1kAnJO7eA7.pgp
Description: PGP signature
