Re: gcc 3.0.1 & C++ ABI issues

[Benjamin Kosnik <bkoz at redhat dot com>]

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

FYI:

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?

best,
benjamin