On Tue, Jul 04, 2000 at 08:19:42PM -0400, Todd Vierling wrote:
> If you're subscribed to source-changes, you'll see an import of gcc 2.95.2
> on Friday into src/gnu/gcc-2.95/dist.  There are some points to note about
> this import, which are listed here to solicit objections or modifications:

Wait. A discussion about a new gcc version came up a while ago, when
Jason was having some problems with C++. At that time, it was brought
up that gcc 2.95.x didn't work well with m68k (code generation bugs),
so that it might not be a good way to go. Since then, Jason has
worked on getting the NetBSD-specific gcc changes into the main
gcc tree, which hopefully should give us good native support in 3.0.

Also, I know Matt Thomas has been doing VAX ELF work using 2.96, I'm not
sure if this is also valid for 2.95.2 or that it would take some effort
to backport that. What's the reason for not picking 2.96? I've heard
that it has problems. Does it have more problems than 2.95.x?

> - gcc 2.9x will not be part of 1.5.x.  This is intentional, because gcc
>   2.9x still has many known issues [bugs] on several architectures that
>   will need to be worked out before a release.  I will not entertain
>   discussion about forklifting it into 1.5, but I will make a pkg available,
>   once integration is completed, for pre-1.6 systems to use the compiler.

Right, 2.9x has known problems, so is it worth it to import it, and
fix those problems? Will that be done before 3.0 comes out? Aren't
we doing work that will be lost soon afterwards if the do?

> - This is not being imported into gnu/dist because the top-level
>   configuration between gcc and other tools (binutils, etc.) is slowly
>   diverging.  Though it's possible to build binutils and gcc from the same
>   tree, it's no longer a regularly tested practice, so the import will focus
>   on keeping the `dist' tree as close as possible to the gcc distribution.

I don't quite follow you here.. I don't see a reason why this should
not be imported (if it's done) into gnu/dist/gcc-2.9x. What does binutils
have to do with it? It doesn't get in the way of gcc, does it?

> - libcc1.so will probably resurface for some ports (or as an option), but be
>   much slimmer, as the common compiler portions have changed a bit since
>   egcs 1.1.  I will also be moving libcc1, and the (now eight) cc1 and
>   related programs, to a subdirectory, /usr/libexec/gcc, to keep them well
>   grouped.

libcc1.so was made static because it didn't save that much space, and
it made things slower. Is there a good reason for bringing in back?

Out current gcc is old and needs to be replaced, that's for sure. I'm
just not sure that 2.95.2 is the right way to go, and I don't understand
the rationale behind the directory structure.

- Frank