This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project. See the GDB home page for more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: do we build a libgdb?



   Date: Mon, 29 Mar 1999 18:03:52 -0800
   From: Ovidiu Predescu <ovidiu@cup.hp.com>

   I am playing around with SWIG and gdb, trying to see what would be needed to
   make the internal GDB functions available to the various interpreted languages
   supported by SWIG. Looking in gdb/Makefile.in I saw there are some references
   to a libgdb target. However they look incomplete as there is no libgdb.a being
   built. Can anybody with access to the CVS repository tell me if such a thing
   existed and was removed in the past?

Indeed a libgdb.a existed and was removed, check out these bits from
ChangeLog-94:

Wed May 25 17:06:15 1994  Jim Kingdon  (kingdon@lioth.cygnus.com)

	* Makefile.in: Replace libgdb.a with libgdb-files.  Make "all"
	build it.

Fri May 13 08:10:21 1994  Jim Kingdon  (kingdon@lioth.cygnus.com)

	* main.c (main): Surround in #ifndef MAIN_OVERRIDE.  Move
	initialization code which needs to be called even if we bypass the
	command line stuff into gdb_init.
	* utils.c (fputs_unfiltered): Surround in #ifndef
	FPUTS_UNFILTERED_OVERRIDE.
	* Makefile.in (libgdb.a): New target.

I don't remember exactly *why* this was changed, although I have a
vague recollection of the .a being deemed an inefficient step in
building GDB, and unnecessary for the purpose of building a GUI.  For
the curious, that GUI project went down in flames a couple months
later, and we ended up doing GDBtk instead, which didn't actually need
libgdb.

This particular libgdb exercise was somewhat pointless, because the
"library" included the full command-line interpreter and everything
else in GDB, just not a main.  So to use it, you have to send commands
and interpret printed output, which offers little advantage over
communicating with a separate GDB.

As I've mentioned before on this list, libgdb is still a good idea, it
just needs a real spec, a correct implementation, and a way to test
that it continues to work.  I'm also willing to support both a simple
libgdb that is GDB - main(), as well as a more sophisticated interface
that provides a total programmatic interface, just as long as both are
done correctly.

							Stan