> "Chris G. Demetriou" <cgd@pa.dec.com> writes:
> 
> > Actually, why didn't you just go to 2.7.2.2 to begin with.  If the
> > differences are only in the configuration files and don't effect
> > operation (which i believe they are), then why do we want to say "we
> > ship 2.7.2.1" rather than 2.7.2.2?
> 
> I was wondering this as well.  I know it doesn't matter, but it is always
> a sore point when we lag so far behind in the compiler tools.

So, looked at one way, the lag is a good thing; we do _NOT_ want to
start using 2.8 or another major release right when it comes out.

On the other hand, things like 2.7.2 -> 2.7.2.1 or 2.7.2.1 -> 2.7.2.2
aren't too significant, because their changes are relatively small and
limited in scope.  That's what made me wonder about the fact that
2.7.2.2 wasn't integrated; the differences between 2.7.2.1 and it are
trivial, from our perspective, so we might as well be running the
later version (if only for version number brownie points from those
who care, or to help make upgrading to a later release easier).


> I wish we could start using the most recent binutils, too, but that
> seems unlikely anytime soon.

I understand that there's likely to be a 2.8.1 soon, so going to 2.8
is probably not a great idea.

In any case, is this really an option for most ports?  All of the
a.out-based ports are stuck with our toolchain until a.out shared lib
support is present in BFD/ld/binutils.  It's just not done yet, right?

Other ports, e.g. alpha, mips, and powerpc, could benefit from having
a different toolchain in the tree, but we (at least alpha and powerpc)
are already sharing a common set of toolchain sources (that we're
packaging up and shipping when we build distributions).


In terms of integrating binutils, there are some specific features
that i'd want to see:

	(1) shared libbfd+libopcodes+libiberty (or whatever the trio
	    that normally gets built into a single shared lib in
	    the standard distribution),

	(2) binutils and ld using that shared lib.

	(3) gdb using that _same_ shared lib.

Yes, i know that gdb is shipped with a seperate bfd et al., but
there's no reason that the same library can't be used, at least with
binutils + gdb of not-too-different vintage.

Certainly, the 2.8 bfd seems to work great with GDB 4.16, with perhaps
one minor change to one header file to fix a slight prototype
difference.


cgd