Daniel Jacobowitz writes: > On Fri, Apr 30, 2004 at 04:05:37PM +0200, Florian Weimer wrote: > > Gregory Seidman <[EMAIL PROTECTED]> 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