public inbox for bfd@sourceware.org
 help / color / mirror / Atom feed
From: Stan Shebs <shebs@cygnus.com>
To: ro@TechFak.Uni-Bielefeld.DE
Cc: gdb-patches@cygnus.com, gdb@cygnus.com, bfd@cygnus.com
Subject: Re: [gdb 19981224] Enable linking gdb against shared libbfd
Date: Wed, 30 Dec 1998 13:55:00 -0000	[thread overview]
Message-ID: <199812302155.NAA19227@andros.cygnus.com> (raw)
In-Reply-To: <13961.11084.647489.224494@xayide.TechFak.Uni-Bielefeld.DE>

   From: Rainer Orth <ro@TechFak.Uni-Bielefeld.DE>
   Date: Tue, 29 Dec 1998 20:19:40 +0100 (MET)

   The following patch is a first shot at linking gdb 19981224 against a
   shared libbfd (tried on IRIX 6.2).  It has a couple of shortcomings:

Thanks, we'll take a look at it.

   * libtool support was added manually to gdb/Makefile.in.  It currently
     lacks the libtool clean targets usually generated by automake's libtool
     support.  This will happen naturally once the gdb Makefile is converted
     to use automake.

We don't have any concrete plans to use automake for GDB, although it's
been talked about.

   * Using a shared libbfd isn't currently very useful since it doesn't
     support proper (in the libtool sense) interface versioning, without
     -release $(VERSION).  Since any release of binutils and gdb comes with
     it's own version of libbfd, there cannot happen any sharing, at least not
     between binutils and gdb.  Are there any plans to convert libbfd to
     proper versioning?  I doubt it is easy, if at all possible, given it's
     constant state of flux.

Exactly, which is why there hasn't been much incentive to try to make the
library shared.  In theory, BFD would only need an internal change from
to time, and would vary little if at all in its interfaces, but in
practice, BFD has to know a number of details about minor OS revisions
and semi-private file formats, so it's proven harder to stabilize than
originally envisioned.

To answer the specific question, I don't know of any plans to do
interface versioning for BFD.  I've cc'ed the bfd list to see if
anyone has more to say.

							Stan

       reply	other threads:[~1998-12-30 13:55 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <13961.11084.647489.224494@xayide.TechFak.Uni-Bielefeld.DE>
1998-12-30 13:55 ` Stan Shebs [this message]
1999-01-03 11:58   ` Ian Lance Taylor
1999-02-20 16:50     ` Jim Blandy
1999-02-21 17:10       ` Ian Lance Taylor
1999-01-07 17:23   ` H.J. Lu
1999-01-08 15:27     ` Rainer Orth

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=199812302155.NAA19227@andros.cygnus.com \
    --to=shebs@cygnus.com \
    --cc=bfd@cygnus.com \
    --cc=gdb-patches@cygnus.com \
    --cc=gdb@cygnus.com \
    --cc=ro@TechFak.Uni-Bielefeld.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).