backward/forward compatibility of binutils

[Mikhail Teterin]

On Friday 07 July 2006 11:40, Dave Korn wrote:
= > Why not? How hard is it to keep API compatibility (no need for ABI)?
= 
= б  Fairly. б If it was trivial, it would be that way already!

More difficult, than for the PNG, EXPAT, or TCL maintainers, for example? I 
know, it is not "trivial", but let's not exclude the middle of "possible, I 
guess" :-)

= > б Why do you insist on every tool bundling its own version?
= 
= б  Well, how about "Because if you bork your system shared libs, and you
= badly need a get-out-of-jail-free card, having statically linked executables
= in your toolchain may well save your life." ?

This is a reason to keep the native tool-chain executables linked statically 
(as well as make, and whatever else is needed to rebuild the shared libs).

This is NOT a reason for each tool bundling its own version... There is not 
one, I think...

A complete, compatible, centrally installed (with headers and both static and 
shared libraries) version of bfd would also allow make installing various 
cross-compilers and cross-debuggers easier, and allow disassembling foreign 
binaries, and analyzing foreign cores.

The linkage mode (such as static for the native cc, ld, as and shared for gdb 
and the non-native tools) can then be decided upon by those, who 
build/package each tool for the system -- I believe, this is addresses your 
point (viz. "get-out-of-jail-free card").

A new version of, say, gdb would not need to include its own bfd anymore -- it 
could simply require one to be present on the system and to be at a certain 
version or higher. Whether or not it ends up linking with it statically is a 
different issue altogether, actually...

Still unsure?

	-mi