Re: G++ 2 => 3 transition (was Re: GNU C++ 3.0 porting help wanted)
On Sun, 2001-10-14 at 16:34, Richard Atterer wrote:
> On Sun, Oct 14, 2001 at 08:42:33PM +0200, Ulrich Eckhardt wrote:
> [big snip]
> > Another issue I found is related to the name-mangling [1] of
> > C++-symbols. The changes between 2.x and 3.x are intentionally
> > incompatible, because the ABI[2] changed too. I found this problem
> > when trying to link with wxWindows, a C++ class-library. The problem
> > will probably only be solvable by recompiling wxWindows with g++-3.0
> > but that too will result in an not backward-compatible change; I
> > have not the foggiest when this will happen nor how this transition
> > will be handled (anyone?).
>
> AFAIK the problem has been raised before, but no solutions have been
> proposed. So I'll have a go... :)
>
> I think the only practical solution for C++ library packages is to
> support both the old and the new ABI during the transition period.
>
> Each library package would build two sets of packages; one
> libfoo/libfoo-dev for GCC 2.x, one for GCC 3.0+. The packages for 2.x
> should probably be in the "oldlibs" section.
>
> I think it will be necessary to have the 2.x packages install their
> files in a directory other than /usr/lib. In this case, that directory
> also needs to be added to the library search path of g++ 2.x and to
> /etc/ld.so.conf.
>
What about, after the freeze on Woody, no libraries usng C++ be accepted
into the new testing (or unstable, whatever) tree unless they are
compiled with gcc 3.0. All applications thus will also have to be
ported, since the libs they depend on will only be using gcc 3.0. We
would probably need two versions of the core libraries (libstdc++) for a
while, though.
This way, we won't have twice the number of C++ packages (which would
greatly increase the archive size), applications would only have to be
ported when their libs were, and libs would have to be ported when a new
application version comes out. You end up with a mechanic sort of
upgrade process, that will only have hickups when dealing with libraries
that are used by a large number of applications (which, although I'm not
sure, is rarer with C++ than for C). Also, maintainers won't be forced
to keep two versions of their packages up to date - they either keep a
gcc 3.0 version up to date, or they are stuck with their old versions.
Again, other than most likely having to use Richard's idea for the core
C++ libraries, I think this method could bring about a rather clean
migration to gcc 3.0 for C++ stuff. I suppose it could aslo be used for
C stuff if that needs porting work, too.
> Cheers,
>
> Richard
>
> --
> __ _
> |_) /| Richard Atterer | CS student at the Technische | GnuPG key:
> | \/¯| http://atterer.net | Universität München, Germany | 0x888354F7
> ¯ ´` ¯
Sean Etc.
Reply to: