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

[Jonathan Wakely <jwakely dot gcc at gmail dot com>]

On 26 June 2010 17:25, Mark Mitchell wrote:
>
> But, I think the high-order bit is Jonathan's comment above: libstdc++

(That was actually Paolo's comment, which I had quoted.)

> is not maintaining backwards-compatibility for its complete interface.
> Jonathan, Paolo, I feel that if that is the case then the SONAME for
> libstdc++ should have changed beetween 4.4 and 4.5. ?And, if there will
> be more incompatibilities in 4.5, then we should change the SONAME
> again. ?Compatibility is binary: either you have it, or you don't.

We have it, for everything built without -std=c++0x.

For programs where -std=c++0x is explicitly used, and one of a handful
of non-functional features are explicitly used (though I struggle to
see how they *can* be used) there is a problem.  I think the set of
users affected by that is empty.

I think changing the soname would be a much bigger problem for a much
bigger group.

The two testsuite failures Matthias found explicitly use -std=c++0x
and explicitly "use" the broken features, because it's our testsuite
and so it tests *everything*. That doesn't mean the tests are
representative of real code anywhere in the world.

> Matthias is focused on the Ubuntu distribution model where they will
> sometimes upgrade the toolchain without rebuilding all the packages.
> But, I think it's at least as important to think about third-party
> software packages. ?If the package fails to run because its missing the
> right libstdc++, the problem is obvious to the user; if it fails to work
> at run-time because of an incompatibility, then it's just "this package
> is broken".

I'm very aware of the effects on third-party packages, and that's a
big reason why I think bumping the soname because of a problem
affecting zero people would cause a lot of bad reactions from users.
We should avoid a situation where a lot of real-world C++ users stick
with the last release before the soname bump and the only users of g++
4.6 and later would be those writing toy programs to test the c++0x
mode.

> 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?  :-)

The libstdc++ maintainers have managed binary compatibility pretty
well IMHO (I don't take any credit for that, most of the effort was
before I was a maintainer.)

A more sensible policy for distros would be to ban the use of
-std=c++0x in their packaging scripts, or at least flag it up as
potentially dangerous. Or require static linking for apps that use
-std=c++0x.