Re: svn commit: r233391 - head/contrib/libstdc++/libsupc++
On Fri, 23 Mar 2012 23:39:44 + 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. -- Alexander Kabaev signature.asc Description: PGP signature
Re: svn commit: r233391 - head/contrib/libstdc++/libsupc++
On Sat, Mar 24, 2012 at 11:54:21AM -0400, Alexander Kabaev wrote: On Fri, 23 Mar 2012 23:39:44 + 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
Re: svn commit: r233391 - head/contrib/libstdc++/libsupc++
Ahem.. On 03/23/12 15:10, David Chisnall wrote: Author: theraven Date: Fri Mar 23 20:10:56 2012 New Revision: 233391 URL: http://svn.freebsd.org/changeset/base/233391 Log: Revert ABI breakage in libsupc++. Unfortunately, the ABI was broken upstream for the 4.2 release, which we imported. We then shipped the broken version for several years and certain ports (e.g. libobjc2) depend on it, so we're stuck with it for now... We should revisit this for 10.0, since we're allowed to break the ABI then, but until then we should keep the ABI we shipped with 8.x and 9.x. Reviewed by: kan Approved by: dim (mentor) MFC after: 1 week Modified: head/contrib/libstdc++/libsupc++/typeinfo Let me try to recap: gcc-4.2.1 broke the ABI and we shipped it for a long time. The bug was detected by Apple and others: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35081 It was fixed for gcc-4.2.2 (which we didn't ship): http://gcc.gnu.org/viewcvs?view=revisionrevision=129061 http://gcc.gnu.org/viewcvs?view=revisionrevision=129061 I inadvertently fixed the bug 3 months ago when I brought in the last LGPLv2 updates for libstdc++: http://svnweb.freebsd.org/base?view=revisionrevision=228780 http://svnweb.freebsd.org/base?view=revisionrevision=228780 The fix hasn't been shipped but was MFC'd and is actually in 8.3-RC* !! David's commit actually restores the gcc 4.2.1 bug (?). Pedro. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
svn commit: r233391 - head/contrib/libstdc++/libsupc++
Author: theraven
Date: Fri Mar 23 20:10:56 2012
New Revision: 233391
URL: http://svn.freebsd.org/changeset/base/233391
Log:
Revert ABI breakage in libsupc++.
Unfortunately, the ABI was broken upstream for the 4.2 release, which we
imported. We then shipped the broken version for several years and certain
ports (e.g. libobjc2) depend on it, so we're stuck with it for now...
We should revisit this for 10.0, since we're allowed to break the ABI then,
but
until then we should keep the ABI we shipped with 8.x and 9.x.
Reviewed by: kan
Approved by: dim (mentor)
MFC after:1 week
Modified:
head/contrib/libstdc++/libsupc++/typeinfo
Modified: head/contrib/libstdc++/libsupc++/typeinfo
==
--- head/contrib/libstdc++/libsupc++/typeinfo Fri Mar 23 20:09:21 2012
(r233390)
+++ head/contrib/libstdc++/libsupc++/typeinfo Fri Mar 23 20:10:56 2012
(r233391)
@@ -100,12 +100,6 @@ namespace std
bool operator!=(const type_info __arg) const
{ return !operator==(__arg); }
-// Return true if this is a pointer type of some kind
-virtual bool __is_pointer_p() const;
-
-// Return true if this is a function type
-virtual bool __is_function_p() const;
-
// Try and catch a thrown type. Store an adjusted pointer to the
// caught type in THR_OBJ. If THR_TYPE is not a pointer type, then
// THR_OBJ points to the thrown object. If THR_TYPE is a pointer
@@ -119,6 +113,12 @@ namespace std
virtual bool __do_upcast(const __cxxabiv1::__class_type_info *__target,
void **__obj_ptr) const;
+// Return true if this is a pointer type of some kind
+virtual bool __is_pointer_p() const;
+
+// Return true if this is a function type
+virtual bool __is_function_p() const;
+
protected:
const char *__name;
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r233391 - head/contrib/libstdc++/libsupc++
On Fri, Mar 23, 2012 at 08:10:56PM +, David Chisnall wrote: Author: theraven Date: Fri Mar 23 20:10:56 2012 New Revision: 233391 URL: http://svn.freebsd.org/changeset/base/233391 Log: Revert ABI breakage in libsupc++. Unfortunately, the ABI was broken upstream for the 4.2 release, which we imported. We then shipped the broken version for several years and certain ports (e.g. libobjc2) depend on it, so we're stuck with it for now... We should revisit this for 10.0, since we're allowed to break the ABI then, but until then we should keep the ABI we shipped with 8.x and 9.x. No, you are not allowed to break ABI for symvered libraries, even between major releases. pgpU0KrKi2vrF.pgp Description: PGP signature
