* Re: [gdb 19981224] Enable linking gdb against shared libbfd
[not found] <13961.11084.647489.224494@xayide.TechFak.Uni-Bielefeld.DE>
@ 1998-12-30 13:55 ` Stan Shebs
1999-01-03 11:58 ` Ian Lance Taylor
1999-01-07 17:23 ` H.J. Lu
0 siblings, 2 replies; 6+ messages in thread
From: Stan Shebs @ 1998-12-30 13:55 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] 6+ messages in thread
* Re: [gdb 19981224] Enable linking gdb against shared libbfd
1998-12-30 13:55 ` [gdb 19981224] Enable linking gdb against shared libbfd Stan Shebs
@ 1999-01-03 11:58 ` Ian Lance Taylor
1999-02-20 16:50 ` Jim Blandy
1999-01-07 17:23 ` H.J. Lu
1 sibling, 1 reply; 6+ messages in thread
From: Ian Lance Taylor @ 1999-01-03 11:58 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] 6+ messages in thread
* Re: [gdb 19981224] Enable linking gdb against shared libbfd
1998-12-30 13:55 ` [gdb 19981224] Enable linking gdb against shared libbfd Stan Shebs
1999-01-03 11:58 ` Ian Lance Taylor
@ 1999-01-07 17:23 ` H.J. Lu
1999-01-08 15:27 ` Rainer Orth
1 sibling, 1 reply; 6+ messages in thread
From: H.J. Lu @ 1999-01-07 17:23 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] 6+ messages in thread
* Re: [gdb 19981224] Enable linking gdb against shared libbfd
1999-01-07 17:23 ` H.J. Lu
@ 1999-01-08 15:27 ` Rainer Orth
0 siblings, 0 replies; 6+ messages in thread
From: Rainer Orth @ 1999-01-08 15:27 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] 6+ messages in thread
* Re: [gdb 19981224] Enable linking gdb against shared libbfd
1999-01-03 11:58 ` Ian Lance Taylor
@ 1999-02-20 16:50 ` Jim Blandy
1999-02-21 17:10 ` Ian Lance Taylor
0 siblings, 1 reply; 6+ messages in thread
From: Jim Blandy @ 1999-02-20 16:50 UTC (permalink / raw)
To: gdb-patches; +Cc: bfd
In a long-ago discussion on whether GDB should use a shared BFD, Ian
Taylor said:
> 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.
Why is including the BFD version in the shared library name preferable
to using -release?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [gdb 19981224] Enable linking gdb against shared libbfd
1999-02-20 16:50 ` Jim Blandy
@ 1999-02-21 17:10 ` Ian Lance Taylor
0 siblings, 0 replies; 6+ messages in thread
From: Ian Lance Taylor @ 1999-02-21 17:10 UTC (permalink / raw)
To: jimb; +Cc: gdb-patches, bfd
From: Jim Blandy <jimb@cygnus.com>
Date: 20 Feb 1999 19:50:31 -0500
In a long-ago discussion on whether GDB should use a shared BFD, Ian
Taylor said:
> 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.
Why is including the BFD version in the shared library name preferable
to using -release?
I'm not sure just what I was thinking, as the current BFD sources
actually do use -release. See libbfd_la_LDFLAGS in bfd/Makefile.am.
I was probably confused. Perhaps I was confusing -release and
-version-info.
I do believe that there is a current problem with BFD shared
libraries, which is that the name of the shared library does not
reflect the configured target. The effect is that you can not
configure BFD more than once with different targets but with the same
prefix.
Ian
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~1999-02-21 17:10 UTC | newest]
Thread overview: 6+ 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:55 ` [gdb 19981224] Enable linking gdb against shared libbfd Stan Shebs
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
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).