Re: Building gdb from source

[Bruce Dubbs <bdubbs@linuxfromscratch.org>]

Dave Korn wrote:

>   Well, if you're replacing your binutils at the same time, what's the
> problem?  The old libs are about to be overwritten in any case!

Actually, the user decides when to add gdb.

>   The point is, that a distro should have a consistent set of gcc, binutils
> and gdb.  Since binutils and gdb live in the same repository, if you either
> take a consistent snapshot of the cvs, or if you take gdb and binutils
> releases that are roughly-contemporary, they're bound to be 'in-sync' FAPP.
> 
>   So if you're building gdb to replace (or even to /be/) your system gdb, you
> should already have chosen one that's compatible with your binutils version,
> or you should be about to replace your binutils to match.  Either way,
> overwriting the old libs won't matter.

From my examination of gdb's source, it looks like it is using
binutils-2.16.91 and the latest stable release of binutils is 2.16.1.
Now this probably doesn't make any practical difference, but we really
don't want our users replacing these files without knowing it.

In any case, another editor pointed me to a workaround:

make -C gdb install

that does the right thing for us.  I suppose the discussion from our
point of view now is really moot, but there are some subtle bugs,
harmless for the most part, in the implementation of binutils' bfd and
libiberty build procedures with regard to the -disable-install-libbfd
and --disable-install-libiberty switches.  I've posted the issue on the
binutils mailing list.

  -- Bruce