Re: Plans for ABI migration

[Bernardo Innocenti <bernie at codewiz dot org>]

On Wednesday 10 January 2001 02:24, Joe Buck wrote:

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

 Of course. gcc 3.0 is supposed to compile C code and output
object modules that can be linked with older libraries,
isn't it?


 > >  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.

 Ouch! This makes the hurry for a 3.x release even greater! And let's
hope it wipes out remnants of 2.x quickly enough.



 > > 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.

 I probably do understimate the difficulty because I don't know all
implications. But I clearly remember that the glibc guy actually
_did_ arrange things so that migrating from libc5 was not as painful
as reinstalling everything from scratch and loosing the ability to
run popular programs such as Netscape (which was available in binary
form only at the time). If they just ignored the problem, some of
us would still be using libc5 today :-)


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

 You're right, but if we don't plan anything reasonable now, each
distribution maker will independently develop a different (and
incompatible) solution to this problem.

 What about asking an opinion to the glibc maintainers? Perhaps
they'll be willing to help.

 Note that I'm not suggesting to stop developement of gcc and
delay the release until everything is perfect. I'm just suggesting
to plan something ahead of time before it becomes a necessity and
people will start hating gcc or fixing it themself.

 What if some distributions choose to install gcc 3.x with
--disable-new-cxx-abi and --disable-libstdcxx-v3 just to minimize
the impact on other packages?


 > >  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).

 They've been blamed enough for releasing an interim gcc snapshot
instead of waiting like the others. Most Linux users I've talked with
would *never* consider installing RH7 because they heard all sort of
stories about it being incompatible and buggy.

 IMHO, by pushing gcc 2.96 ahead of time, RedHat has helped all other
distributions to make the transition to 3.x easier. All major UNIX
projects (C or C++) have now been fixed to build with 2.96 as well
as older compilers, which makes it much easier to update them for
3.x too. Even the Linux kernel has been recently revised to build
correctly with 2.96 (but they're still careful). If RH didn't do
that move, today nobody will be caring to test and fix their code
on anything newer than 2.95.3.

 Ok, I know this is a very hot topic and I don't want to start a
flame war again. That's just my very personal opinion.

 


 > 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.

 That's right. Break it whatever you want. Break it again in the
future if you need to. But please plan a small kludge for ld.so to
make the transition a little easier.

 On each new release, glibc guys change the values of some constants
in header files, the types of function parameters and even the
semantics of some function calls. They can do this safely because
they use symbol versioning.

 We can't use this same solution, but we can come up with something
different that solves the problem for us.


 > >  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.

 It would work! You could even switch form ELF to a.out when you set
up things so that the user can keep two sets of libraries.

 What I'm suggesting is a kludge like this in /etc/ld.so.conf:

       /usr/i486-linux-gcc2=gcc2abi
       /usr/lib

 If ld.so could tell which compiler has been used to build the
module being loaded, it could switch to the correct library set.

 Embedding this information somewhere in the ELF binary image
shouldn't be hard to do. We could even put some special symbol
in crt0.o that ld.so could look for. This is probably better
than my original idea. It does only require a small change that
doesn't affect the compiler nor the binutils.

 Let's say crt0.o distributed along with gcc contains the symbol
"__gcc_abi_version_3". This would be enough for ld.so to do the
rest, I guess.

 This addresses only shared libraries. But we can safely ignore
archive libraries because it's easier to replace them without
breaking existing applications.


 > >  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).

 By the way, what's the rationale behind setting up libstdc++ as
a shared library by default? It contains only small routines that
wouldn't increase the size of a C++ program too much. It's quite a
pain to have all those libstdc++ versions around, expecially
because it doesn't address the problem of a C++ library linking to
a specific version of libstdc++ which is used by a program linked
with another version.

-- 
  // Bernardo Innocenti
\X/  http://www.codewiz.org