svn commit: r233391 - head/contrib/libstdc++/libsupc++
kabaev at gmail.com
Sat Mar 24 15:54:29 UTC 2012
On Fri, 23 Mar 2012 23:39:44 +0000
David Chisnall <theraven at 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
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 188 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/svn-src-head/attachments/20120324/2fd76075/signature.pgp
More information about the svn-src-head