This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: backward/forward compatibility of binutils
п'ятниця 07 липень 2006 12:30, Jan-Benedict Glaw написав:
> Forget that, quickly. If you install one set of toolchains, once, you
> get away with that. But if you follow development where CPU features
> are added all the time, you likely end up with a dozend installations
> of libbfd, along with header files.
Why would I end up with "dozens installations", instead of one, that's the
most recent?
If the API compatibility is accepted as desired (which is what I'm trying to
achieve), it will be possible to recompile the older versions of the tools
against the new bfd's headers -- with minimum, if any, effort...
I may sound arrogant, but I don't see, how the bfd is different from, again,
JPEG or PNG -- it provides a way to deal with different binary formats, not
entirely unlike the different image formats (there are many kinds of PNGs
too, BTW).
Things are, of course, trickier, when the tools have to deal with live
processes (and kernels), but those areas are tiny and require a great deal of
OS/arch level customization anyway...
> Conceptionally, there is no such thing like a "stand-alone,
> feature-complete libbfd".
Sorry for the confusion -- I did not mean "feature-complete". By "complete" I
meant, that support for all formats known at the compile time is compiled in.
> It's highly interwoven with the tools, and both will be adopted matching
> each other whenever a change is needed.
So, there is no one straightforward development trunk (with minimally
incompatible branches), but a whole bush of versions, which are slightly
incompatible with each other? This appears to have been the case some years
ago, and I am saddened, that it remains so...
п'ятниця 07 липень 2006 13:25, Ian Lance Taylor написав:
> Don't expect it to happen by asking on this mailing list. It will not
> solve any problem faced by the binutils developers. Instead, it will
> require a great deal of extra work. So just asking us to implement it
> will accomplish nothing.
So far, I can't even get an agreement, that it would be a good thing! Even if
I did all of this "great deal of extra work", it would still be rejected...
On the other hand, if/when this agreement is reached, the actual amount of
work would not be so huge -- there is little (if anything) to REDO. Just keep
the desirability of backwards compatibility in mind _going forward_.
Yours,
-mi