RE: backward/forward compatibility of binutils

["Dave Korn" <dave dot korn at artimi dot com>]

On 07 July 2006 17:31, Jan-Benedict Glaw wrote:
> On Fri, 2006-07-07 12:15:32 -0400, 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" :-)
> 
> For sure, yes. Just look at binutils and its users. Every now and
> then, there's an extension to some processor architecture imposing new
> defines etc. Each time, you have to increase the version number of the
> libbfd. That way, if you install binutils and gdb at two times, you're
> likely ending up with one lib for each, as well as two sets of header
> files.
> 
> For eg. file parsing libraries like PNG, there's not much that changes
> in the PNG standard over the time. For processors and their features,
> a lot changes. All the time.

  And consider the scale of the changes between Dwarf-2 and Dwarf-3.  Any old libbfd that was written before Dwarf-3 could never have anticipated and provided extensibility for all those new features.

>> 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...
> 
> You will probably face quite a hard time linking different snapshots
> of objdump, gdb, readelf etc. with one single libbfd. Every time new
> features are included (or existing features are changed), all
> components in the `src' CVS repository will be touched. That just
> won't work.
> 
>> Still unsure?
> 
> Yap.  Conceptionally, there is no such thing like a "stand-alone,
> feature-complete libbfd". It's highly interwoven with the tools, and
> both will be adopted matching each other whenever a change is needed.


  Yes, this is at the crux of it.  Gdb, for example, is highly tied to the debugging data format.  Although gdb could *in theory* be rewritten to examine the libbfd, find out what version you have, deduce which features it supports and which it doesn't, it would take a VAST amount of work, which would quickly become out-of-date.  Much better for gdb to be tied to bfd, so that it 'just knows' what features are supported and which aren't.  After all, wouldn't people be disappointed if they downloaded and installed a new gdb and it *still* didn't come with the latest features (like Dwarf-3 parsing) because they had to change their system libbfd as well?


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....