This is the mail archive of the
mailing list for the GCC project.
Re: gcc 3.0.1 & C++ ABI issues
- To: gcc at gcc dot gnu dot org, nathan at codesourcery dot com, mark at codesourcery dot com, jason at redhat dot com
- Subject: Re: gcc 3.0.1 & C++ ABI issues
- From: Benjamin Kosnik <bkoz at redhat dot com>
- Date: Mon, 6 Aug 2001 09:24:45 -0700
> I think we should fix this on the mainline, but not on the branch.
> Our current working assumption is that the ABI for the library is
> going to change wildly on the mainline, forcing recompilation for most
> people in 3.1 anyhow, and so we can hide minor core ABI changes
> beneath that cover. This case seems precisely analagous to the
> overloaded operator delete stuff that I found.
I'm planning on checking in a patch today that officialy breaks the
library ABI, and bumps the version of the library to 3.1.0 on mainline.
In all fairness, this should have been done a month ago. I'm using the
following metric for changing the library ABI: The first change that
either adds, deletes, or changes a mangled symbol get a minor version
bump from the previous, stable version. I use this metric because I
know of no other, and it seems sensible: please correct me if I'm wrong.
Also, testing of this seems completely straightforward.
I remain curious as to what the criteria for changing the compiler ABI
will be: there seem to be lots of little things going in, and I'm not
quite sure people are really testing for ABI breakage, or even really
looking at this. Am I wrong? Can somebody please elaborate on what is
going on? Is it just assumed that the mainline g++ ABI is 3.1.x?