Re: Removal of V2 code

[Mark Mitchell <mark at codesourcery dot com>]

>>>>> "Geoff" == Geoff Keating <geoffk@geoffk.org> 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