Re: C++ ABI change for etch -- freeze unstable for all C++ libs with changed or new sonames
On Sun, Jun 05, 2005 at 05:12:46PM +0200, Matthias Klose wrote:
> Adrian Bunk writes:
> > On Sun, Jun 05, 2005 at 01:25:28PM +0200, Matthias Klose wrote:
> > >...
> > > - freeze unstable for uploads of library packages with new ABI
> > > versions. If a new soname is introduced now, it has to be changed a
> > > few weeks later again. Packages depending on these libraries
> > > would need to be uploaded twice as well.
> > >...
> > > The time frame of the C++ ABI changed is not yet fixed. We will
> > > certainly need some time to get the toolchain in shape to start the
> > > transition. In the meantime you can check the new compilers in
> > > unstable (g++-3.4) and in experimental (g++-4.0), the new binutils in
> > > experimental (2.16), and the new glibc in experimental (2.3.5).
> >
> > Doesn't this cause the same issue as with sarge where the transition was
> > too early and could have been to a more recent gcc version if done
> > later?
>
> which issue?
>
> > It's not unlikely that gcc 4.1 will be released in 2005.
> >
> > The C++ ABI might change again in gcc 4.1 .
>
> the world might become flat again.
The issue with sarge is that it ships with gcc 3.3 as default compiler
although it could have shipped with gcc 3.4 .
The issue with etch is that there might be enough time to wait for
gcc 4.1 before doing the transition and immediately go to gcc 4.1 then.
Shipping sarge with gcc 3.3 and etch with gcc 4.0 doesn't the world stop
from turning. But as far as I can see the big batch of work is the
transition. And if one transition can be a bigger step forwards, that
doesn't sound like a bad idea.
> > If the C++ transition was half a year from now to gcc 4.1, it was still
> > 6-12 months before the date your release team plans to release etch.
>
> If it's 6 month before the release, it's definitely too late.
Silly question:
Why?
I see the following critical tasks of a gcc transition (you have to
change gcc-defaults and perhaps a few other things, but they shouldn't
cause any problems):
1. ensure that the whole archive builds with the new default compiler
2. doing the C++ transition
The C++ transition seems to be the easier part, since it mostly requires
updating all C++ libraries and packages using C++ libraries. This is a
serious amount of packages, but it's pretty straightforward.
Reagarding the first part, gcc 3.4 and 4.0 compile errors are already
reported in the BTS and hopefully resolved pretty soon. And unless the C
or C++ frontends of gcc 4.1 will reject a serious amount of code their
gcc 4.0 counterparts accepted, this should only generate a manageable
amount of problems.
Yes, a gcc transition takes some time. But with the experiences of the
sarge transition to gcc 3.2 and the Ubunto transition to gcc 4.0, where
exactly in the transition do you expect problems that couldn't be solved
within 2 or 3 months after the start of the transition?
And whether I like it or not, the resulting three months before the
release would still be before the start of the first part of the freeze
in the schedules of your release team.
> Matthias
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Reply to: