On Sun, 15 Oct 2000, Geoff Keating wrote: > > Date: Sat, 14 Oct 2000 20:13:59 -0400 > > From: Daniel Jacobowitz <[EMAIL PROTECTED]> > > > > > 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.
