This is the mail archive of the gdb-patches@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] |
> > Some global symbols are defined in gdb/main.c (eg. gdb_stdout, > > gdb-stderr, etc). As the result if I'm building all except main.c in > > object library to use with some IDE that uses gdb for debugging > > (rhide-1.4.7), I'm getting unresolved references. > > Um, wow. It never occurred to me that anyone would try that. I did that already since years in RHIDE and it worked perfectly. Now I have reviewed the latest gdb sources and saw that the problem really exists and I'm not happy about this change. > is that we don't want to get into maintaining GDB with this kind of > application in mind. If we turn GDB into a library, we should do it > right --- design an interface that makes sense, document the > interface, make sure that future changes preserve the boundaries, etc. > My guess is that that would be more work than we really want to take > on. So my question is now: Why does exist there a file called libgdb.texi in the doc directory? I know now, that this file describes only an imaginary library which does not exist, but if there exists such a description of a libgdb the maintainer of gdb should think also a little bit about that people, who did the hard job to integrate the gdb functionality also in other programs even when it is not the described libgdb but a lib with the same goal. > > An alternative idea could be duplicating init code and global > > vrariables in rhide. > > I think this is your best bet. This is not the best but only for now the shortest solution, since it will force me to change every time my duplicated code when something related to it will change in the future in the gdb sources. BTW: There is not only an describtion of the imaginary libgdb, but there is also a target in the Makefile which is called libgdb-files, which creates a file containing all the names of the object files for the libgdb. So if, main.o is not part of it, but main.o conatains code which is refered by other files, than this is a bug. Robert ****************************************************** * email: Robert Hoehne <robert.hoehne@gmx.net> * * Post: Am Berg 3, D-09573 Dittmannsdorf, Germany * * WWW: http://www.tu-chemnitz.de/~sho/rho * ******************************************************