Re: Plans for ABI migration

[Joe Buck <jbuck at racerx dot synopsys dot com>]

Note: we are talking here about the C++ ABI, not the C ABI.

>  It's perfectly good to change the ABI or the API if it needs
> improvement.

It does: the currently released (in 2.95.x or Red Hat "2.96") libstdc++ is
so far from standards conformance that it's a bit embarrassing.  The
current name mangling scheme is horribly inefficient and generates mangled
symbols 10,000 characters long for some internal names in commonly used
things like map<string,string>, breaking assemblers on some platforms.

> What's utterly wrong is not doing anything to help
> the users migrate to the new interface, expecially when this
> goal would be very easy to achieve.

You underestimate the difficulty.  What we can do, and what we are
doing, is to arrange things so that this will be the last ABI change
for a long time.

The responsibility for smooth migration lies with distribution makers.
That doesn't mean that the gcc team won't help, of course.

>  I call myself an experienced user: I'm usually not scared of
> scrambling my system to upgrade glibc or other core packages,
> but I really don't have the heart to install gcc 3.0 at this time:
> how many executables would I break if I started compiling my
> libraries with it? The cascade of recompilations that would be
> needed is not acceptable.

Then clearly Red Hat 7 must be a failure in the marketplace.  Right?
After all, users must recompile all C++ programs for it, and then
they'll have to do it again (yes, I know that there are ways around
this, just as there will be for 3.0).

In practice, as you say, this ABI breakage has discouraged the use of C++,
so we want it to stop.  But in order to make it stop, we must break the
ABI in a big way one last time.

>  The more I think on it, the more I come to the conclusion that
> the only way to address this problem is fiddling with ld.so like
> the glibc guys did to migrate from libc5.

Won't work.  The ABI change is too great; object layouts completely
change.

>  > You assume that this is a new problem.  Distribution makers
>  > already know how to handle it.  There is an unavoidable disk
>  > space cost.
> 
>  Acceptable, as long as programs distributed in binary form
> can still be installed on a gcc 3.x system.

Certainly.  For C++ shared libraries, you'll need multiple versions.
For the basic libraries, distribution makers will provide those
multiple versions.  Distributors of binaries also have the option of
doing static linking of their C++ code for greater portability (e.g
statically link all C++ libraries other than libstdc++, for libstdc++,
distributions will already have the version that is needed, or it
can be installed as an optional package).