Re: Next C++ transition

[Matthias Klose <doko@cs.tu-berlin.de>]

Daniel Jacobowitz writes:
> On Fri, Apr 30, 2004 at 04:05:37PM +0200, Florian Weimer wrote:
> > Gregory Seidman <gss+debian@cs.brown.edu> writes:
> > 
> > > On Fri, Apr 30, 2004 at 01:31:53PM +0200, Florian Weimer wrote:
> > > } Are there any plans how handle the next C++ transition, and when to
> > > } start it?
> > >
> > > Is there one on the horizon? I thought the 3.x series was maintaining
> > > binary compatibility throughout.
> > 
> > The soname of libstdc++ changed upstream from 3.3. and 3.4, and the
> > compiler implements a somewhat different flavor of C++ (it's much
> > closer to the standard now).
> 
> However, with symbol versioning and shared libgcc implemented in both
> 3.3 and 3.4, I don't think a transition is actually necessary - I
> believe things will work OK with both versions linked in.  For most
> architectures, at least.
> 
> Do you have some reason to think this is wrong?

yes, at least on hppa and m68k. The exception handling is changed from
sjlj based to dwarf2 based exception handling, which not only requires
recompilation of C++ and Java files, but every C file compiled with
-fexceptions (maybe these can be identified having undefined
references to the unwind functions?). In the release notes, alpha mips
and sparc are listed to have changes in the binary ABI, maybe only
corner cases.

Technically we can build 3.4 with sjlj exceptions on hppa and m68k and
let the ABI version default to 1 (compatible to 3.3 according the
docs).  Noone tried, noone tested this ... at least java built on hppa
with these settings doesn't look sane.

So do we have a plan? From my point of view:

1) get sarge released, do nothing to delay the release. The transition
   from 2.95 to 3.2 took us some months.
2) iff we can get gcc-3.4 into sarge as a techology preview, that
   whould be fine. At least it provides us with a java interpreter
   and compiler available for all platforms and may help moving
   more java packages from contrib to main.
   gcc-3.4 replaces libgcc1, libobjc1, libffi2 and libg2c0
   A script comparing the exported symbols of libraries built by the
   3.3 and 3.4 compilers seems to be ok. tested on p.d.o, so someone
   should review this. As long as gcc-3.4 is used for package building
   that level of compatibility should be ok.
3) When sarge is released, prepare for the transition. As outlined
   this means the same as the 2.95 to 3.[23] transition. plus:
   - transitioning every library depending on libgcc1 referring the
     unwinding symbols and rebuilding every application depending on
     these libraries.
   Technically this is only needed for m68k and hppa (ignoring the
   ABI changes on alpha, mips and sparc). But this way we end up
   having different library package names for some architectures.
   That may work, but it looks error prone.
4) When gcc-(3.4)++ gets released, GCC wants to be on the bright side
   of compatibility. At least the libstdc++ and C++ ABIs should
   stay compatible. Let's assume this will happen, we maybe have 
   the same situation as for the transition from 3.2 to 3.3: Mostly 
   works. But ... between 3.4 and it's successor the ABI for the 
   ARM architecture is supposed to be changed.  Goto 3), prepare for
   the transition, ...

There are currently too many unknown things like sarge's release date,
GCC's (3.4)++ release date, new glibc versions ... Options may range
from releasing sarge+1 with gcc-3.3, gcc-3.4, gcc-3.4 with non-default
options or gcc-(3.4)++ (skipping gcc-3.4 as the default compiler).

	Matthias