Mirror of the gdb mailing list
 help / color / mirror / Atom feed
* Re: [gdb 19981224] Enable linking gdb against shared libbfd
       [not found] <13961.11084.647489.224494@xayide.TechFak.Uni-Bielefeld.DE>
@ 1998-12-30 13:56 ` Stan Shebs
  1999-04-01  0:00   ` Ian Lance Taylor
  1999-04-01  0:00   ` H.J. Lu
  0 siblings, 2 replies; 4+ messages in thread
From: Stan Shebs @ 1998-12-30 13:56 UTC (permalink / raw)
  To: ro; +Cc: gdb-patches, gdb, bfd

   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


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [gdb 19981224] Enable linking gdb against shared libbfd
  1998-12-30 13:56 ` [gdb 19981224] Enable linking gdb against shared libbfd Stan Shebs
@ 1999-04-01  0:00   ` Ian Lance Taylor
  1999-04-01  0:00   ` H.J. Lu
  1 sibling, 0 replies; 4+ messages in thread
From: Ian Lance Taylor @ 1999-04-01  0:00 UTC (permalink / raw)
  To: shebs; +Cc: ro, gdb-patches, gdb, bfd

   Date: Wed, 30 Dec 1998 13:55:13 -0800
   From: Stan Shebs <shebs@cygnus.com>

      * 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.

Correct: there are no current plans to use -release when building a
BFD shared library.

I believe the correct solution for BFD is to rename the shared library
based on the BFD version number.  However, this is not currently
implemented.

Ian


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [gdb 19981224] Enable linking gdb against shared libbfd
  1999-04-01  0:00   ` H.J. Lu
@ 1999-04-01  0:00     ` Rainer Orth
  0 siblings, 0 replies; 4+ messages in thread
From: Rainer Orth @ 1999-04-01  0:00 UTC (permalink / raw)
  To: H.J. Lu; +Cc: Stan Shebs, gdb-patches, gdb, bfd

H.J. Lu writes:

> However, the ABI of libbfd changes quite often. A system
> wide libfd may not work very well. You may not use libbfd from
> binutils 2.9.1 with gdb 19981224. If you are suggesting make

that's why I asked about proper library versioning and interface stability
in libbfd.  But the responses indicate that this won't happen for quite
some time, if at all.

> libbfd in gdb shared, I don't see any benefit to do so since
> the shared libbfd may only be safely used with the gdb where
> the libbfd comes from. Also on Linux, I make the whole gdb binary
> static. It is very useful when you work on C libraries.

:-)  But generally unnecessary on commercial Unixes.  As I said, if you
could share one libbfd between binutils and gdb, that would save some
space.

	Rainer


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [gdb 19981224] Enable linking gdb against shared libbfd
  1998-12-30 13:56 ` [gdb 19981224] Enable linking gdb against shared libbfd Stan Shebs
  1999-04-01  0:00   ` Ian Lance Taylor
@ 1999-04-01  0:00   ` H.J. Lu
  1999-04-01  0:00     ` Rainer Orth
  1 sibling, 1 reply; 4+ messages in thread
From: H.J. Lu @ 1999-04-01  0:00 UTC (permalink / raw)
  To: Stan Shebs; +Cc: ro, gdb-patches, gdb, bfd

> 
> 
>    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:
> 

I have been using shared libbfd for binutils for a long time
on Linux. I just added "--enable-static=no --enable-shared".
I used it only because libbfd is quite big and there are many
programs in binutils linked against it.

However, the ABI of libbfd changes quite often. A system
wide libfd may not work very well. You may not use libbfd from
binutils 2.9.1 with gdb 19981224. If you are suggesting make
libbfd in gdb shared, I don't see any benefit to do so since
the shared libbfd may only be safely used with the gdb where
the libbfd comes from. Also on Linux, I make the whole gdb binary
static. It is very useful when you work on C libraries.


H.J.


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~1999-04-01  0:00 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <13961.11084.647489.224494@xayide.TechFak.Uni-Bielefeld.DE>
1998-12-30 13:56 ` [gdb 19981224] Enable linking gdb against shared libbfd Stan Shebs
1999-04-01  0:00   ` Ian Lance Taylor
1999-04-01  0:00   ` H.J. Lu
1999-04-01  0:00     ` Rainer Orth

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox