Re: libstdc++-v3 stability?

[Benjamin Kosnik <bkoz at redhat dot com>]

> My concern however is that while the C++ ABI may be stable, what
> about the libstdc++ ABI?  It seems like it would only take a small
> tweak to the signature of an app-visible method, and then an old
> app would not be able to dynamically link to a newer libstdc++
> dylib, which means that you've have to keep around a copy of the
> previous libstdc++.  Darwin does have a dylib versioning mechanism,
> but I'd hate to have millions of iMac disks filled up with dozens
> of libstdc++ versions 1/2 :-)  (Yes, I know Microsoft does just
> that with DLLs, but I'd like to do better.)

I just got asked this question by Red Hat, yesterday.

Since it seems to be the issue du jure with OS vendors, I'll tell you 
what I told them:

1) The library ABI for gcc-3.1.x will remain fixed for the life of gcc-3.1.
This means no-ABI-breaking fixes in gcc-3.1.x's libstdc++. We tried to do 
this with gcc-3.0.x, but lack of symbol versioning got in the way.

2) I'm suggesting source-compatibility for standards-compliant C++. 
Binary-compatibility issues between gcc-3.1.x and gcc-3.2.x can be dealt 
with via compatibility-libraries, the same as for a "C" library. 

3) I'm interested in working with you on versioning. I'm planning on 
adding ELF versioning sometime next month: it would be helpful if we 
could coordinate work on this so that versioning works for both of us.

This seems sane, at least to me. Jason, Mark, Gaby, others?

If this is unclear, please let me know and I'll try to expand or explain.

-benjamin

ps. Again, I plead for visible test results on Darwin, using the 
configuration and setup that Apple does builds with. This will save 
everybody time.