From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Mitchell To: geoffk@redhat.com, geoffk@geoffk.org Cc: gcc@gcc.gnu.org Subject: Re: Removal of V2 code Date: Sun, 19 Nov 2000 21:52:00 -0000 Message-id: <20001119215157C.mitchell@codesourcery.com> References: <20001119175608K.mitchell@codesourcery.com> <200011200424.UAA00653@geoffk.org> X-SW-Source: 2000-11/msg00860.html >>>>> "Geoff" == Geoff Keating writes: >> Put simply, I don't think that is an issue for the FSF >> release. None of these platforms are on primary release >> criteria list. Geoff> I didn't understand this part, and so I couldn't understand Geoff> much of the rest of your mail either. Sorry. I was referencing the list of platforms that the SC has decided are primary targets for GCC 3.0; none of those targets are embedded systems. Geoff> What does the release or the release criteria have to do Geoff> with it? I was objecting to the deletion of libstdc++-v2 Geoff> from the development tree, on the grounds that this would Geoff> make it harder to do development. I would have no Geoff> objection to its deletion from the release branch, if it's Geoff> doing the right thing, go ahead. The problem is that these things aren't entirely orthogonal. The ABI, the library version, and the performance of the compiler are all intertwined. It's not just the question of dragging the sources around; it's more complex than that. There's also the issue that port maintainers need to invest the effort to switch to V3 because that's what we're going to support going forward. I'd really like to get a handle on whether that porting effort is truly difficult or not. (It wasn't difficult on the platforms I worked on, but, on the other hand, it has been pointed out that those were both SVR4-ish platforms.) Geoff> The counter-example here is i960; there are no non-embedded Geoff> alternatives (the choices are -coff, -elf, and -vxworks), Geoff> and it does have C++ support. OK. But I still don't really understand the scenario you're talking about. It seems to me there are a few cases: - Change to the i960 back-end in your tree. You can test in your tree, and you can test C/Fortran/ObjC in the public tree. By hypothesis, the public tree doesn't have i960 C++ support any more, since the scenario we're talking about is one where we don't have V2 in the public tree, and V3 doesn't work on the i960. So, nobody can complain about your change breaking i960 C++. - Change to the C++ front-end in your tree. Likely this change is not i960-specific. You can test with another chip. If it *is* i960 specific, then you're in the same boat as above: there's no i960 C++ support anyhow. So, I'm afraid I still don't understand the testing argument. Is there anyone out there who is willing to try a newlib port of V3? Is it possible to build newlib on an i686-pc-linux-gnu box, using it natively, instead of glibc? If so, would you tell me how to do this? Or, alternatively, a way to build a cross-compiler plus simulator so that I can test a newlib configuration on my PC? If you will tell me how to build all the pieces, I will try to figure out how to make V3 work in that environment. If I were to make that work, would that reduce your objection to removing the V2 sources? -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com