This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Difficulty for community involvment in gdb
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Subject: Re: Difficulty for community involvment in gdb
- From: Erland Lewin <erl at voxi dot com>
- Date: Thu, 02 Aug 2001 13:34:31 +0200
- CC: gdb at sources dot redhat dot com
- References: <3B684397.40704@voxi.com> <3B686235.30809@cygnus.com>
Andrew Cagney wrote:
> When I went to close your two bug reports the first thing I did was
> try to find the SID bug-tracking system so that I could point you at
> it. Unfortunatly that doesn't exist.
Thank you for that effort.
> One thing that would help though. What lead you to check out both SID
> and GDB in a single source tree? I'm guessing that this is documented
> somewhere and hence, would like to locate that documentation so that
> those responsible can be informed of the problems you encountered.
Ok, I think I figured this out now, and this seems to be the root of my
problems.
My standard way of getting changes from a cvs repository is to type:
"cvs -q update -Pd". This also retrieves new directories. In all other
projects which I've gotten cvs versions from, this works, and is good
because it retrieves new directories which are normally neccessary.
However, in the gdb cvs, this gets a number of other directories which
I apparently don't want to have.
I assume this is becuase these directories are what most projects
treat as cvs modules.
Would it be possible for the gdb cvs repository to treat these other
directories as modules as well, to conform to what I feel is the common
way of using cvs?
Otherwise, a comment in the cvs section of the gdb homepage warning
against doing updates as I did might be in order.
> Regarding Linux threads, you may want to just download/build a current
> GDB. More bugs then are worth mentioning have been fixed.
I did and took a quick look at it.
From what I could see it still leaked threads (although this was not
as a big a problem as before, because it could create over 500 threads I
think. However, with enough threads this will surely become a problem).
I've seen some discussions about lin-threads, but no documentation
about this. Do I need to do anything special to debug threads under
Linux? I now have glibc-2.2.2.
Also, I had problems starting gdb. It said
> ./gdb
ide_initialize_paths failed: Can't find the GUI Tcl library in the
following directories:
/usr/src/programming/gdb-cvs/build/usr/share/cygnus/gui
/usr/src/programming/gdb-cvs/build/share/cygnus/gui
/usr/src/programming/gdb-cvs/share/cygnus/gui /usr/libgui/library
/usr/src/programming/gdb-cvs/build/usr/share/cygnus/ide
/usr/src/programming/gdb-cvs/build/share/cygnus/ide
/usr/src/programming/gdb-cvs/share/cygnus/ide /usr/libide/library
But maybe this is due to me having all those extra directories in place
when configuring gdb.
I got around that by doing unsetenv DISPLAY.
> With PRMS vs Bugzilla, it is a decision we live with. I think the
> time to review it is when GDB+BINUITLS get merged with GCC.
Ok.
> If you would like a gnats account that can be arranged.
That would be nice.
Thanks for your time and attention,
Erland