On Fri, 2006-07-07 14:41:12 -0400, Mikhail Teterin wrote: > п'ятниця 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... 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. > 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. 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? > > 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. You can, of course, take any libbfd snapshot. But after all, it's just a random collection of functions. There's no strict interface or API for it, that's why it's different compared to other libs, like libjpeg and the like. > > 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... In the trunk of the CVS repository, there's the Latest and Greatest version, as well as properly hacked binutils/gdb/... to use this. There are branches, but from my point of view, the trunk is most important. And for trunk, you're better off taking every post-commit state as a completely unrelated and new _version_ of the whole set of tools. If there's a good reason to move functions around or change them, they'll just be changed, along with their callers. > п'ятниця 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... It will be accepted in the sole case that defining a definitive API for libbfd doesn't make it harder to freely move code around and change it. Remember, its current state is "highly interwoven", instead of "a clearly separate work." > 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_. Who'll implement backward compatibility code? ...or alternatively increase the library version number? Does compatibility code add bloat to the lib? Is there an easy way to exclude it from a compilation run? Do all the binutils and gdb need extra code (or configury) to get the currently installed libbfd's configuration? Who'll write that? Does it add bloat to the binutils/gdb codebase? Can this be excluded for a compilation run? 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!), but I just realized that making a real lib out of it is just a horrid hard piece of fruitless work. 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));