Re: glibc 2.1.95 (5th test release)
On Sun, 15 Oct 2000, Geoff Keating wrote:
> > Date: Sat, 14 Oct 2000 20:13:59 -0400
> > From: Daniel Jacobowitz <dan@debian.org>
> >
> > > It strikes me that it might be a good idea to set up a branch on
> > > sourceware gcc to mark the date of the C++ ABI that glibc 2.2-based
> > > ppc linux distributions use, if y'all want to share the same ABI. My
> > > suggested date would be the snapshot before 20000905T000500Z.
> >
> > I'm not at all sure I want to go this route. We're more or less
> > committed to using the same GCC on all our architectures. After the
> > amount of flak Red Hat is taking for using a snapshot, even with a good
> > understanding of the issues, I'm not sure that it's a good idea to do
> > the same.
> >
> > If I understand correctly, Debian had been looking vaguely at testing
> > GCC snapshots, but was certainly not planning on shipping with them
> > until at least much closer to 3.0.
> >
> > What are the odds we could use this to merge the relevant fixes onto a
> > 2.95 branch again? I understand that the differences are staggering
> > and the manpower short, but is it a feasible task? I don't have a
> > whole lot of time, but I would be willing to do what I can to see this
> > happen.
>
> At Red Hat, we had about six months once the choices became apparent,
> and you can see what choice we made. I personally have no time (in
> fact, probably negative time) to do it in; I'll be lucky to get a
> working glibc with the not-publicly-available toolchain I'm using now.
>
> I believe that if we had been able to predict the strength of the
> reaction to using a GCC snapshot in our main Linux distribution, we'd
> have consulted more in advance about the possible choices but
> ultimately we would have still done it, because there were no other
> good choices. The position for Debian is a bit different, because you
> don't sell compiler support; one of the big factors influencing our
> choice was that we didn't want to be supporting a four-year-old
> compiler in 2002.
>
> Well, I'll let you guys worry about it. Tell me if you do want a branch.
Hmm, I think I would rather prefer to apply my current backport patchset to
the gcc-2_95-branch... Contrary to RH, on PPC we use gcc-2.95.x since a long
time, so C++ binary compatibility is a issue for us (though I have yet to see
a problem with the mainlines libstdc++-v2, I should see problems with shared
runtime linking, or?). With a gcc-2.96 branch we would then have 3 C++ ABI's
to maintain for a while, gcc-2.95.x, gcc-2.96, and gcc-3.0. For creating a
PPC mainline branch, I would prefer to wait until the mainline switches to
the new ABI, libstdc++-v3, integrated libgcj and the SUBREG_BYTE stuff. And
shortly after that gcc-mainline will enter the gcc-3.0 stabilization phase
anyway, so a separate PPC branch wouldn't make much sense.
This is all based on the assumption that the gcc-3.0 stabilization phase will
be entered during the next 2-4 month, which seems realistic with the current
planned release schedule of 6-8 month. If the stabilization get's delayed by
much more, we would probably have to rethink this though, cause this probably
would conflict with the release schedule of some distributions.
Note that I have absolutely no objections against the current mainline vs.
code correctness on PPC, my current experiences are very good with it. I
haven't done any benchmarks yet, but it seems that at least the size of
produced C code is better.
So for now I would prefer to bring the gcc-2_95-branch to a state where it
can correctly compile glibc-2.2, and this is what my patchset does at least
for PPC.
Franz.
Reply to: