This is the mail archive of the
mailing list for the GCC project.
Re: C++ ABI Issues
- From: Benjamin Kosnik <bkoz at redhat dot com>
- To: mark at codesourcery dot com
- Cc: gcc at gcc dot gnu dot org
- Date: Mon, 26 Aug 2002 20:28:38 -0700
- Subject: Re: C++ ABI Issues
- Organization: Red Hat / San Francisco
> I propose that we fix G++ to match the ABI, but that we issue warnings
> about classes whose layout has changed from GCC 3.2.
> If we are going to fix G++, we also have to decide how urgently to do
> another release.
You seem to be very cavalier about the downstream impacts of changing
the C++ ABI, and what this means for sane tool versioning.
Every time you change the underlying compiler ABI, libstdc++ has to
adapt and meaningfully mark the changing versions.
I do not think doing a g++ release, and bumping __GXX_ABI_VERSION to
103, and changing libstdc++.so.5 to libstdc++.so.6, and updating
GLIBCPP_3.2 to GLIBCPP_3.3, and CXXABI_1.2 to CXXABI_1.3 should happen
every three months.
You found bugs, great. You fixed the bugs, even better. I bet you
fifty bucks you find more by the end of December, or two tickets to a
Giants home game, whichever is more.
Please, let's not do another release where we have a two week period
to find bugs. That's insanity. Instead, let's actually have some kind
of public, check-in-and-GPL'd ABI testsuite g++ users can cling to and
say, hey! We have an ABI and here's what we are checking.
If I were king, I'd say, finish up the codesourcery ABI tester. Fix
all the bugs you find. Then, do a bug-fix ABI release in a year, after
g++ has successfully shown to be inter-operable with another compiler
so it actually means something.
Sorry if this sounds pissy. I know you are working on the side of
angels, but please. Try not to abuse your considerable power. Let's
try to come up with a long term plan for managing C++ ABI changes, and
stop calling "FIRE!!!" every time there is a bug. Pretty soon nobody
yours in struggle,