backward/forward compatibility of binutils

[Jan-Benedict Glaw]

On Fri, 2006-07-07 15:46:17 -0400, Mikhail Teterin <mi+mx@aldan.algebra.com> wrote:
> п'ятниця 07 липень 2006 15:02, Jan-Benedict Glaw написав:
> > How often do you see a change in the format of a JPEG picture, for
> > example? Right, there've been some five or six changes over the time.
> >
> > How often do you see new processor architectures, new architectural
> > features or simply new ABIs come up? That's more like a weekly
> > business.
> 
> These don't require abandoning the existing architectures/ABIs weekly. (And 
> frankly, I'm unconvinced of the bfd's super-fluid mobility. Windows/x64 has 
> been around for years now, but is still not supported, for example...)

Look for changes in eg. the MIPS code.

...and a system not being supported only states one single fact:
Nobody cared enough about that system to implement whatever needs to
get implemented.

Compare to: Some months ago, some guy found a teeeny bug in the PDP11
code. There were two independant (and equal) fixes for this issue
within a day or two.

> > Sometimes, these are even exclusive, so the callee better knows about
> > that. You could implement a number of feature-checking functions to
> > libbfd, and call these from all callers, but is this worth it?
> 
> I don't see ImageMagick unduly suffering from the quickly evolving png, jpeg, 
> tiff, jasper, mng, jbig, freetype, fontconfig, and Perl.

When was the last change to these formats that also affected the
implementation of older versions?

Keeping a stable version is _easy_ if you only extend functionality,
but not, if functionality _changes_.

> For another example, we have not seen any trouble ever since the FreeBSD ports 
> of Mozilla-derived browsers switched to using the centrally-built (and 
> tightly tested!) nspr and nss modules.

These have a well-defined interface. libbdf doesn't have that. It's
just a random collection of functions.

> > I guess these are the main questions to answer. Just to cut a long
> > story short, I am a user of a "standalone" libbfd which I'm using for
> > disassembling. Initially I also thought that a fixed API would help me
> > (to not need to change my program every now and then, which I
> > definitively needed to do!), 
> 
> Having to change a program to work with the most recent release of bfd is fine 
> and acceptable. What is not acceptable is having a bunch of different bfds, 
> which all require different changes...

This is why there's one trunk version.

> > but I just realized that making a real lib out of it is just a horrid hard
> > piece of fruitless work.
> 
> Poor initial design, no one willing to fix it (and even some scorn poured at 
> the outsiders advocating improvement). All of the implorations of CS 
> professors have been in vain...

Yap, that's a possibly valid point of view. But unless patches (with
copyright assignments in place) show up, nothing will change.

MfG, JBG

-- 
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 für einen Freien Staat voll Freier Bürger"  | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <https://sourceware.org/pipermail/binutils/attachments/20060707/d55a45ca/attachment.sig>