svn commit: r233391 - head/contrib/libstdc++/libsupc++

David Chisnall theraven at FreeBSD.org
Fri Mar 23 23:40:00 UTC 2012


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...

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 :-(

David


More information about the svn-src-head mailing list