running 4.4 libstdc++ testsuite using 4.5's libstdc++ shared library

[Jonathan Wakely]

On 27 June 2010 17:07, Mark Mitchell wrote:
> Jonathan Wakely wrote:
>
>>> Meanwhile, Matthias, I think you should consider the impact of the fact
>>> that the libstdc++ maintainers are not yet in a position to guarantee
>>> long-term binary compatibility on the dual-toolchain strategy used in
>>> Ubuntu.
>>
>> Ahem, hasn't every libstdc++-v3 soname bump been made because the
>> front end was already breaking the ABI, not the library?  :-)
>
> You're clearly taking something personally here.  You shouldn't; I
> wasn't criticizing anyone.  And, for the record, yes, I personally
> introduced bugs in the front-end that affected the ABI, and, yes, the
> C++ ABI (like C++0x) went through a period of evolution that caused
> incompatibilities, and yes, that's unfortunate.

Not personally, but I misunderstood the statement about not being in a
position to guarantee long-term binary compatibility as saying we
couldn't guarantee it today, even between 4.4 and 4.5, which isn't the
case.  If you meant that the ABI would change some day, then I
completely agree and apologise for overreacting.

> But, I would like to see agreement on is that changes to the ABI, even
> for C++0x, even when -std=c++0x is required, require an SONAME change.
> Experimental or not, once the feature goes in the library, it's in the
> library.

Yes, I agree.

The ABI will have to change one day, and the soname will change then,
but in practice we can't just introduce changes and bump the soname
(see e.g. http://gcc.gnu.org/ml/libstdc++/2009-07/msg00036.html for
one statement strongly against ABI changes.)  Instead we have to hold
back on making changes at all, or figure out how to do them
compatibly.

I would like to see a situation where we either ship two libraries, or
a single library using inline namespaces or symbol versioning to
provide two incompatible versions in the same file.  I don't know
which option is better or how to achieve it, but it might be time to
figure that out soon.

Sorry for being antagonistic,

Jonathan