This is the mail archive of the
mailing list for the GCC project.
Re: Removal of V2 code
> From: Mark Mitchell <firstname.lastname@example.org>
> Date: Sun, 19 Nov 2000 17:56:08 -0800
> >>>>> "Geoff" == Geoff Keating <email@example.com> writes:
> Geoff> The embedded platforms (*-elf, powerpc-eabi*, *-coff) don't
> Geoff> work yet with V3; I don't believe anyone, certainly not at
> Geoff> Red Hat, will be able to fix this until next month; we
> Geoff> don't have time.
> Put simply, I don't think that is an issue for the FSF release. None
> of these platforms are on primary release criteria list.
I didn't understand this part, and so I couldn't understand much of
the rest of your mail either.
What does the release or the release criteria have to do with it? I
was objecting to the deletion of libstdc++-v2 from the development
tree, on the grounds that this would make it harder to do development.
I would have no objection to its deletion from the release branch, if
it's not needed for the release.
I don't really care. I just wanted to try to avoid a possibly
annoying mistake. If you really think you're doing the right thing,
> I should think that you could find a stock i686-pc-linux-gnu system to
> test platform-independent changes on. :-) And for most chips (MIPS,
> PowerPC, etc.) I bet you have non-embedded alternatives to test
> back-end changes on. There may be rare chips for which this is not
> possible, but there is likely either no C++ support for those chips at
> all in the FSF tree, or there is a non-embedded target for which you
> simply do not have access to appropriate hardware. In that case, I'm
> sure that either someone will provide you access to the hardware, test
> your patch themselves, or that you can go ahead and check it in, and
> let the people with the right hardware check out what happens.
The counter-example here is i960; there are no non-embedded
alternatives (the choices are -coff, -elf, and -vxworks), and it does
have C++ support.
- Geoffrey Keating <firstname.lastname@example.org>