Re: GCC 3.0 status?
On Mon, Jun 25, 2001 at 11:13:25PM -0400, Joey Hess wrote:
> Wichert Akkerman wrote:
> > It is an extremely bad thing since it means we loose binary
> > compatability with both other Debian releases and all other Linux
> > distributions. That is not something I want happen with Debian.
> >
> > What we need is:
> > * be sure that everything actually compiles with g++-3.0. The hppa
> > porters are rapidly discovering that is not the case.
> > * talk with other distributions and see how they plan to transitition
> > * come up with a strategy that ensures we won't suddenly break
> > binary compatibility in unexpected ways.
>
> If this does indeed take some time (which sure seems likely), perhaps it
> would be a good idea to move the existing gcc-3.0 packages from priority
> standard to priority extra in the meantime. As is, they are selected
> automatically by dselect, and worse, are being installed as part of all
> new installs of woody..
Apologies for the delay in responding to this...
I wrote and released the first three versions of libstdc++-v3.
I don't think this binary compatibility matter is as important
as it might seem.
The fact is, each version of libstc++ released so far has been,
formally, binary-incompatible with every other. Each program and
library compiled against libstdc++ headers has been binary-incompatible
with every other program and library compiled against a different
version of headers.
The libraries for g++-3 (the GNU project traditionally does not
append a ".0" on major releases) are, in this sense, no different.
Yes, the variety of binary-incompatibilities is much larger, but so
what? Different is different.
It is not necessary to build every program and library against the new
library and compiler, any more than before; it is sufficient to have on
hand all the library versions needed to run the programs included in
the release. You want most of them on hand anyway to allow Potato
programs to continue to run.
Binary compatibility for C++ libraries will become more important
some time after gcc-3.1, when the library interface to libstdc++
begins to stabilize. This is similar to the glib-1.x -> glibc-2.x
transition: there will not be a glibc-3 (knock wood) because
the glibc team has committed to the glibc-2 binary interface --
at least for backward compatibility of documented facilities.
Big C++ library interfaces can be harder to stabilize than C libraries,
because of the greater variety of language features that expose
implementation details, for better performance or flexibility.
Before you commit to a binary interface, you have to be sure you
have made the right exposure/performance tradeoffs, and that's a
lot of detail work.
Once the binary interface to libstdc++ is frozen, then it will no
longer be necessary to keep older builds of libstdc++[23].x around,
just as it is not necessary to keep old glibc-2.x versions. Then,
other libraries and programs built against the older versions of
libstdc++ will work with the newer ones too. The first step of that
freeze was the new standard ABI for the compiler itself.
When libstdc++'s user-visible implementation has been tuned and
declared stable, then will be a good time to make the jump en mass.
I think such an effort may not be so valuable now.
Nathan Myers
ncm at cantrip dot org
Reply to: