This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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));
Attachment:
signature.asc
Description: Digital signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |