Re: [Patch] libstdc++/14493

[Benjamin Kosnik <bkoz at redhat dot com>]

> this is the result of the recent discussions in mailing list and audit 
> trail, pretty straightforward at this point. I'm going to wait a bit in 
> case there are better options for gnu.ver: not knowing well the 
> rationale behind the CXXABI tag, I was rather surprised to find 
> std::bad_alloc::~bad_alloc exported as a generic library, not libsupc++ 
> symbol (it belongs to the latter, strictly speaking). In the below I'm 
> simply continuing the tradition, adjusting the existing exports and 
> adding some for the what method (at 3.4.11, because we may want to 
> commit the debug-mode thread safety fixes separately in 4_2-branch).

Hey Paolo. Sorry for the delay.

First off: I think the non-versioning parts of this patch are great. 
Kudos for fixing this long-standing issue in a consistent way. (As an 
aside, reading through that bug report: I miss Phil! His email is always 
quite funny, and intentionally so.)

Clearly, as a QoI issue, users like demangled strings in error messages. 
 We opened the door a bit with __verbose_terminate_handler and clearly 
that set expectations for everybody for demangled names. (And I prefer 
them too.) So, verbosity wins.

We should remember this when doing future work.

To address your question about libsupc++ symbols exported in GLIBCXX 
instead of CXXABI, the answer is pretty simple: the symbols in question 
are in namespace std. I can see where you are coming from, but I think 
the current behavior is defensible. We're trying to keep namespaces as 
the notation for versioning, and I think this is being done consistently 
 with all the various versioning options.

Anyway, on to the versioning issue.

The last released libstdc++ is 6.0.8 in gcc-4.1.1. It looks like 
gcc-4.1.2 will also have this version, which corresponds to GLIBCXX_3.4.8.

The versioning for all unreleased gcc's should all be equivalent, and 
start with

GLIBCXX_3.4.9

Therefore, it looks like mainline is currently wrong: what's in 
GLIBCXX_3.4.10 should be in GLIBCXX_3.4.9 (and those changes should go 
to gcc-4_2-branch) and the new changes that you propose should also go 
in GLIBCXX_3.4.9 (and also go in gcc-4_2-branch.)

Capiche?

Then everything will be in sync again. The goal is to keep mainline and 
gcc-4_2-branch in sync, symbol-wise until gcc-4.2.0 is officially 
released. (And after that, in sync for as long as possible.)

-benjamin