From: Mikhail Teterin <mi+mx@aldan.algebra.com>
To: Jan-Benedict Glaw <jbglaw@lug-owl.de>
Cc: Dave Korn <dave.korn@artimi.com>,
"'Daniel Jacobowitz'" <drow@false.org>,
binutils@sources.redhat.com,
Ian Lance Taylor <iant@google.com>
Subject: Re: backward/forward compatibility of binutils
Date: Fri, 07 Jul 2006 19:46:00 -0000 [thread overview]
Message-ID: <200607071546.18147.mi+mx@aldan.algebra.com> (raw)
In-Reply-To: <20060707190224.GJ22573@lug-owl.de>
ц░'ц▒ц■ц▌ц┴ц┐ц▒ 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
next prev parent reply other threads:[~2006-07-07 19:46 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-07 6:50 Mikhail Teterin
2006-07-07 12:51 ` Jan-Benedict Glaw
2006-07-07 13:22 ` Daniel Jacobowitz
2006-07-07 13:28 ` Jan-Benedict Glaw
2006-07-07 14:44 ` Mikhail Teterin
2006-07-07 15:11 ` Daniel Jacobowitz
2006-07-07 15:32 ` Mikhail Teterin
2006-07-07 17:27 ` Ian Lance Taylor
2006-07-07 15:40 ` Dave Korn
2006-07-07 16:18 ` Mikhail Teterin
2006-07-07 16:30 ` Jan-Benedict Glaw
2006-07-07 16:39 ` Dave Korn
2006-07-07 18:42 ` Mikhail Teterin
2006-07-07 18:45 ` 'Daniel Jacobowitz'
2006-07-07 18:56 ` Mikhail Teterin
2006-07-07 18:58 ` 'Daniel Jacobowitz'
2006-07-07 19:02 ` Jan-Benedict Glaw
2006-07-07 19:46 ` Mikhail Teterin [this message]
2006-07-07 20:29 ` Jan-Benedict Glaw
2006-07-07 20:33 ` Christopher Faylor
2006-07-07 20:33 ` Ian Lance Taylor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200607071546.18147.mi+mx@aldan.algebra.com \
--to=mi+mx@aldan.algebra.com \
--cc=binutils@sources.redhat.com \
--cc=dave.korn@artimi.com \
--cc=drow@false.org \
--cc=iant@google.com \
--cc=jbglaw@lug-owl.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).