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