Re: backward/forward compatibility of binutils

[Mikhail Teterin <mi+mx at aldan dot algebra dot com>]

п'ятниця 07 липень 2006 15:02, Jan-Benedict Glaw написав:
> > 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...
>
> As long as the library version is correct, right.  But right now,
> every now and then, there's an incompatible change and nobody cares to
> think long about it.

This "nobody cares to think long about" part is exactly what I'd like changed.

> > 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).
>
> 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...)

> 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.

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.

> 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...

Unfortunately, your experience confirms that of the FreeBSD developers, who 
tried to centralize the binutils libraries in one location, and gave up 
(although, NetBSD, I think, succeeded in some shape or form).

> 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...

	-mi