From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stan Shebs 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 Message-id: <199812302155.NAA19227@andros.cygnus.com> References: <13961.11084.647489.224494@xayide.TechFak.Uni-Bielefeld.DE> X-SW-Source: 1998/msg00082.html From: Rainer Orth 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