Re: Plans for ABI migration

[Bernardo Innocenti <bernie at codewiz dot org>]

On Tuesday 09 January 2001 22:16, Joe Buck wrote:

 > Bernardo Innocenti writes:
 > > did the steering comitee already set a roadmap to ease the
 > > migration from the old C++ ABI (gcc 2.9x) to the new one
 > > (gcc 3.x)?
 >
 > No, because there is nothing special about an ABI change with a
 > major release of the compiler.  Some background:
 >
 > In the past, the C++ ABI broke with every major release.  egcs 1.0
 > was different from 2.7.x.  egcs 1.1 was different from egcs 1.0.
 > gcc 2.95 was different from egcs 1.1.  Red Hat's "2.96" is
 > not compatible with either 2.95 or current snapshot code.
 > In many cases, these changes were required by the effort to support
 > more and more of an evolving language standard.  But the ISO C++
 > has been complete for some time, and we'll now have an almost
 > complete (except for template "export" and the usual bugs)
 > implementation of C++.

 It's perfectly good to change the ABI or the API if it needs
improvement. 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.

 Ok, in the past each new revision of g++ carelessly changed
the C++ ABI, causing all sort of pain to the users and distribution
makers. Even if it's now become customary, it would still be
good to do something about it.

 By the way, 2 years ago you could count popular C++ programs
for Linux on your hands. Today with QT, KDE, GTK-- and all that
stuff, many basic packages you can find in any Linux distribution
depend on the C++ ABI.

 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.

 Nobody will migrate to gcc 3.x if it's such a pain. Authors
of popular C++ libraries such as avifile will never test their
code with it and never release binary packages for other
developers. As a result, nobody will want to use it.


 > >  This is expecially needed for systems using gcc as their
 > > official C++ compiler, such as Linux and *BSD.
 >
 > The problem has been dealt with in the past by the shared library
 > version number: you can run binaries that use older and newer C++
 > by having multiple shared libraries on your machine.  If you have
 > a GNU/Linux box, do
 >
 > ls /usr/lib/libstdc++*
 >
 > You will see that there is more than one shared library.
 > Unfortunately other C++ libraries such as QT will also need multiple
 > versions.  This sucks, but there's nothing we can do about it.

 For libstdc++ it's just ugly (I've got 6-7 revisions of it!), but
we can all live with it. libstdc++ comes with g++, so it's guaranteed
to be in sync with the compiler.

 All other libraris (QT, KDE, avifile, etc.) won't magically
change their major version number when compiled with gcc 3.0.


 > What is new is that we intend to "stop the insanity" and have
 > g++ 3.1 still be binary compatible with g++ 3.0.  We know that
 > we'll still have to make changes to fix bugs, but approaches
 > similar to those used for glibc will be used so that one library
 > can support multiple compiler versions.

 You mean by using symbol versioning like glibc does? It's already
possible now, and quite a good solution when only a few symbols
differ from one version to another.

 The first problem that comes to my mind is that you must have
multiple compiler versions installed (and I doubt today's
compiler drivers handle -V2.95.2 or -V2.91.66 correctly).

 Then, you must link together two sets of object modules to build
a single library containing both versions. It still requires
major fiddling with build system of 3rd party libraries and so
it's not possible like bumping their revisions.

 Alternatively, gcc 3.x could generate code for multiple ABIs
at the same time, which would be a mess to maintain for the
gcc developers.

 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.

 
 > >  This is going to be quite a pain for most users and even
 > > for distribution makers unless something is done to allow
 > > a smooth migration scheme.

 > 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.
 
-- 
  // Bernardo Innocenti
\X/  http://www.codewiz.org