Re: backward/forward compatibility of binutils

[Jan-Benedict Glaw <jbglaw@lug-owl.de>]

[-- Attachment #1: Type: text/plain, Size: 3127 bytes --]

On Fri, 2006-07-07 12:15:32 -0400, Mikhail Teterin <mi+kde@aldan.algebra.com> wrote:
> On Friday 07 July 2006 11:40, Dave Korn wrote:
> = > Why not? How hard is it to keep API compatibility (no need for ABI)?
> = 
> =   Fairly.  If it was trivial, it would be that way already!
> 
> More difficult, than for the PNG, EXPAT, or TCL maintainers, for example? I 
> know, it is not "trivial", but let's not exclude the middle of "possible, I 
> guess" :-)

For sure, yes. Just look at binutils and its users. Every now and
then, there's an extension to some processor architecture imposing new
defines etc. Each time, you have to increase the version number of the
libbfd. That way, if you install binutils and gdb at two times, you're
likely ending up with one lib for each, as well as two sets of header
files.

For eg. file parsing libraries like PNG, there's not much that changes
in the PNG standard over the time. For processors and their features,
a lot changes. All the time.

> This is a reason to keep the native tool-chain executables linked statically 
> (as well as make, and whatever else is needed to rebuild the shared libs).
> 
> This is NOT a reason for each tool bundling its own version... There is not 
> one, I think...

Actually, there isn't one version for each tool. Don't only have a
look at the released tarballs, but also at the CVS server. You'll find
out that there's only one libbfd.

> A complete, compatible, centrally installed (with headers and both static and 
> shared libraries) version of bfd would also allow make installing various 
> cross-compilers and cross-debuggers easier, and allow disassembling foreign 
> binaries, and analyzing foreign cores.

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.

> A new version of, say, gdb would not need to include its own bfd anymore -- it 
> could simply require one to be present on the system and to be at a certain 
> version or higher. Whether or not it ends up linking with it statically is a 
> different issue altogether, actually...

You will probably face quite a hard time linking different snapshots
of objdump, gdb, readelf etc. with one single libbfd. Every time new
features are included (or existing features are changed), all
components in the `src' CVS repository will be touched. That just
won't work.

> Still unsure?

Yap.  Conceptionally, there is no such thing like a "stand-alone,
feature-complete libbfd". It's highly interwoven with the tools, and
both will be adopted matching each other whenever a change is needed.

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 #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]