Difficulty for community involvment in gdb

Difficulty for community involvment in gdb

[Erland Lewin]

Hello,

I've just spent several hours trying to figure out how to build gdb from 
cvs (I'm an experienced developer and I'm still not there yet).
  In the process I've exchanged some E-mail with Frank Eigler (who's 
been very helpful) and Andrew Cagney.
  Basically, the current problem is that there is no accurate 
documentation that I could find to build gdb from the cvs repository. 
The top level Makefile says:

    It is now possible to automatically configure and build a variety of
   tools with one command.  To build all of the tools contained herein,
   run the ``configure'' script here, e.g.:

However, this doesn't work with for instance SID.
  Anyway, I ended up complaining to Frank (because he would listen):

    So to a newcomer to this stuff, it would seem that bdf, sid etc are
    "part of gdb". It's quite difficult to get started with the cvs.
     Additionally, the gnats interface is IMHO not as good as bugzilla.
    The only thing I can do, not being a developer, seems to be to
    create bug reports; I can't add comments to them.
     I think little problems like the ones I'm having inhibit the
    advantage that gdb could get from greater community involvment. What
    I'm really trying to do is to get gdb to work better with threads
    under Linux. This has been a problem for several years (I
    contributed a patch for this about two years ago). I think the time
    it takes for these things to get fixed will be longer if it is more
    difficult for people to get involved.
     End of rant [:-)]


And he replied: "I hear ya. You should repost this set of observations 
to gdb@sources.redhat.com where they can get a wider airing.". So here 
they are.

  Hoping that someone will listen,

    Erland

Re: Difficulty for community involvment in gdb

[Andrew Cagney]

Just FYI,


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.  Looking at the e-mail exchange it 
would appear you were unfortunatly given the impression that this was a 
GDB problem which it isn't, sigh.

>    It is now possible to automatically configure and build a variety of
>   tools with one command.  To build all of the tools contained herein,
>   run the ``configure'' script here, e.g.:

I'll try to clarify the comment in that file.


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.

> So to a newcomer to this stuff, it would seem that bdf, sid etc are
>    "part of gdb". It's quite difficult to get started with the cvs.
>     Additionally, the gnats interface is IMHO not as good as bugzilla.
>    The only thing I can do, not being a developer, seems to be to
>    create bug reports; I can't add comments to them.
>     I think little problems like the ones I'm having inhibit the
>    advantage that gdb could get from greater community involvment. What
>    I'm really trying to do is to get gdb to work better with threads
>    under Linux. This has been a problem for several years (I
>    contributed a patch for this about two years ago). I think the time
>    it takes for these things to get fixed will be longer if it is more
>    difficult for people to get involved.


Regarding Linux threads, you may want to just download/build a current 
GDB.  More bugs then are worth mentioning have been fixed.

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.  If you would 
like a gnats account that can be arranged.

	Andrew





	Andrew

Re: Difficulty for community involvment in gdb

[Erland Lewin]

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

Re: Difficulty for community involvment in gdb

[Keith Seitz]

On Thu, 2 Aug 2001, Erland Lewin wrote:

>  > ./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

Since you did the "cvs update -d", you picked up Tcl, Tk, Itcl, Tix, blah,
blah, and gdb/gdbtk. In other words, insight. (See
http://sources.redhat.com/insight .)

You can always run an insight executable with the "-nw" flag to suppress
the gui. (Or configure with "--enable-gdbtk=no" or get rid of all the
superfluous directories, especially gdb/gdbtk.)

Keith

Re: Difficulty for community involvment in gdb

[DJ Delorie]

>   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 

A more correct way to update a module set is to do this:

	cvs -q get gdb

Unless your cvs is quite old, this *is* an incremental update *plus*
any new directories *defined by the module*.  You can't do that with
"cvs update".