Subject: Re: gcc/binutils/gdb import proposal
To: Todd Vierling <email@example.com>
From: Andrew Cagney <firstname.lastname@example.org>
Date: 07/17/2000 14:57:05
> : everything else looks great, though i don't really get the point of
> : moving everything in to usr.bin/binutils...i'd just get rid of the
> : binutils directory there entirely. i think, in particular, moving
> : GDB there is wrong.
> Well, I wanted at least to group those things found in a distribution. What
> prompted me to move gdb inside was that it uses libbfd (and comes
> from the same Redhat source tree); we've already run into users who forget
> to build bfd before binutils, gas.new, ld.new, and gdb.
> It's... awkward, I'll admit, but as long as gdb comes with a "don't forget
> to build libbfd!!" warning, it can go outside gnu/usr.bin/binutils.
I'm offended! GDB is not BINUTILS :-)
More seriously, you may want to think a little more about how you're
The expectation is that the GDB, BINUTILS and GCC repositories will
eventually be merged. To this end, people already have scripts
available that can create local merged source trees and then build
them. In addition, people making changes to certain sources (eg
libiberty) must merge their change back into the master GCC tree.
However, even if/when GDB, BINUTILS and GCC do get merged, I'd not hold
your breath waiting for a synchronized GDB + BINUTILS + GCC release.
GDB 5.1, which isn't that far away (xmas?) will have far better NetBSD
support (thanks to J.T. and Matthew) than 5.0. How is that going to be
merged if GDB/BINUTILS are trying to share a common BFD yet the BFD in
5.1 has significant changes?
Anyway, I can see several choices:
o largely independant
GCC, BINUTILS, GDB
o single unified GDB,
BINUTILS and GCC source
o unified GCC+BINUTILS
but indepedant GDB. The
consequences of importing
GDB's are not as serious
as importing new GCCs or
I don't know which is better for your needs.
mumble something about head GDB maintainer
PS: While I've your attention. Assuming you drag in GDB 5.0 and then
make local changes, could you please remember to tweek
gdb/Makefile.in:VERSION so that the GDB identifies its self as something
other than ``GDB 5.0''. Otherwize, when (not if :-) someone reports a
bug against ``gdb 5.0'' there is no way of determinging which 5.0 they
are refering to. (Oh, and please not 5.0.0.x, I've already been through
that nightmare with 4.18 - I've lost count of how many unofficial
22.214.171.124's there were .... :-)