Re: Difficulty for community involvment in gdb

[Erland Lewin <erl at voxi dot 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