RE: Insight build problem on cygwin

RE: Insight build problem on cygwin

[Rolf Campbell]

> -----Original Message-----
> From: Keith Seitz [mailto:keiths@redhat.com] 
> Sent: Thursday, February 13, 2003 5:02 PM
> To: Chris Faylor
> Cc: Rolf Campbell; insight@sourceware.org
> Subject: Re: Insight build problem on cygwin
> 
> 
> On Thu, 2003-02-13 at 13:07, Christopher Faylor wrote:
> > Wasn't this supposedly with the cygwin net release binary 
> version of 
> > insight?
> 
> Oh. That complicates things.
> 
> >   That wouldn't be affected by this.
> 
> I think it may have... Rolf said that "-nx" allows insight to 
> run. I believe the problem was that he has a register window 
> open. Try this... Run insight with no executable. Open the 
> register window. It'll crash with an internal error (which 
> may or may not be visible on cygwin...)
> 
> Keith

I ran "insight -nx", then I click "View"->"Registers".  I get a message
box "Quit this debugging session?", and then "Create a core file for
GDB?".  If I say no to both, then the register window does open, with no
values.

-Rolf

RE: Insight build problem on cygwin

[Keith Seitz]

On Thu, 2003-02-13 at 14:04, Rolf Campbell wrote:
> I ran "insight -nx", then I click "View"->"Registers".  I get a message
> box "Quit this debugging session?", and then "Create a core file for
> GDB?".  If I say no to both, then the register window does open, with no
> values.

Ok, that's it. That's the bug I just "fixed":

2003-02-11  Keith R Seitz  <keiths@redhat.com>

        * generic/gdbtk-register.c (register_changed_p): If the selected
        frame is NULL, do not call frame_register_read, since that will
        now cause an internal error.

Keith

Re: Insight build problem on cygwin

[Rolf Campbell]

Keith Seitz wrote:
> On Thu, 2003-02-13 at 14:04, Rolf Campbell wrote:
>>I ran "insight -nx", then I click "View"->"Registers".  I get a message
>>box "Quit this debugging session?", and then "Create a core file for
>>GDB?".  If I say no to both, then the register window does open, with no
>>values.
> 
> 
> Ok, that's it. That's the bug I just "fixed":
> 
> 2003-02-11  Keith R Seitz  <keiths@redhat.com>
> 
>         * generic/gdbtk-register.c (register_changed_p): If the selected
>         frame is NULL, do not call frame_register_read, since that will
>         now cause an internal error.
> 
> Keith
Ok, I'm now running "2003-02-15-cvs (cygwin-special)" from the cygwin 
net binary release.  The problem associated with opening the registers 
window is gone, but I still cannot launch insight without "-nx".

Re: Insight build problem on cygwin

[Keith Seitz]

On Sat, 2003-02-15 at 14:11, Rolf Campbell wrote:
> Ok, I'm now running "2003-02-15-cvs (cygwin-special)" from the cygwin 
> net binary release.  The problem associated with opening the registers 
> window is gone, but I still cannot launch insight without "-nx".

Hmm. Do you have this patch?

2003-02-14  Keith Seitz  <keiths@redhat.com>

        From Chris Faylor <cgf@redhat.com>:
        * generic/gdbtk-main.c (main): Initialize args.interpreter_p.

If so, could you explain to me what happens when it doesn't start? (I'm
building a cygwin version now, but it'll take several hours.)

Keith

Re: Insight build problem on cygwin

[Rolf Campbell]

Keith Seitz wrote:
> On Sat, 2003-02-15 at 14:11, Rolf Campbell wrote:
> 
>>Ok, I'm now running "2003-02-15-cvs (cygwin-special)" from the cygwin 
>>net binary release.  The problem associated with opening the registers 
>>window is gone, but I still cannot launch insight without "-nx".
> 
> 
> Hmm. Do you have this patch?
> 
> 2003-02-14  Keith Seitz  <keiths@redhat.com>
> 
>         From Chris Faylor <cgf@redhat.com>:
>         * generic/gdbtk-main.c (main): Initialize args.interpreter_p.
Well, I don't know for sure, but since it was Chris who released the 
cygwin version on the 15th, I suspect that he included his own patch.

> If so, could you explain to me what happens when it doesn't start? (I'm
> building a cygwin version now, but it'll take several hours.)
> 
> Keith


It does 0.8 seconds of absolutely nothing (no text output, no error 
message, nothing), then terminates.

Re: Insight build problem on cygwin (tentative patch enclosed)

[Christopher Faylor]

On Mon, Feb 17, 2003 at 11:49:05AM -0500, Rolf Campbell wrote:
>It does 0.8 seconds of absolutely nothing (no text output, no error 
>message, nothing), then terminates.

I can duplicate this.  I don't know what I was doing when I "tested"
this net release but it fails miserably to debug anything.  How
embarrassing.

The problem is that uiout is being set to NULL in interp_set() because
that is what is stored in the interpreter structure set up in
_initialize_gdbtk.

I've included a patch below.  I made it as minimal as possible so
that it is obvious what I did.  It may make more sense to move
gdbtk_init later in the code and include the static definition of
tk_procs into it.

Boy, this interp stuff sure screwed things up.  Aren't we supposed to
not severely break existing functionality when we check in new gdb
features?

cgf

Index: gdbtk.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbtk/generic/gdbtk.c,v
retrieving revision 1.33
diff -u -p -r1.33 gdbtk.c
--- gdbtk.c	12 Feb 2003 16:02:03 -0000	1.33
+++ gdbtk.c	17 Feb 2003 17:01:40 -0000
@@ -69,6 +69,7 @@ extern void _initialize_gdbtk (void);
 static sigset_t nullsigmask;
 static struct sigaction act1, act2;
 static struct itimerval it_on, it_off;
+static const struct interp_procs tk_procs;
 
 static void
 x_event_wrapper (int signo)
@@ -593,6 +594,7 @@ gdbtk_init (char *argv0)
   gdb_stdlog = gdbtk_fileopen ();
   gdb_stdtarg = gdbtk_fileopen ();
   uiout = cli_out_new (gdb_stdout);
+  interp_add (interp_new ("gdbtk", NULL, uiout, &tk_procs));
 
 #ifdef __CYGWIN32__
   (void) FreeConsole ();
@@ -749,22 +751,19 @@ gdbtk_command_loop (void *data)
 }
 
 /* Come here during initialize_all_files () */
+static const struct interp_procs tk_procs =
+{
+  tk_init,
+  gdbtk_resume,
+  gdbtk_suspend,
+  gdbtk_exec,
+  gdbtk_prompt_p,
+  gdbtk_command_loop,
+};
 
 void
 _initialize_gdbtk ()
 {
-  static const struct interp_procs tk_procs =
-  {
-    tk_init,
-    gdbtk_resume,
-    gdbtk_suspend,
-    gdbtk_exec,
-    gdbtk_prompt_p,
-    gdbtk_command_loop,
-  };
-
-  interp_add (interp_new ("gdbtk", NULL, NULL, &tk_procs));
-
   /* FIXME: cagney/2003-02-12: This is wrong.  The initialization
      should be done via the init function.  */
   if (use_windows)

Re: Insight build problem on cygwin (tentative patch enclosed)

[Keith Seitz]

On Mon, 2003-02-17 at 09:04, Christopher Faylor wrote:
> I can duplicate this.  I don't know what I was doing when I "tested"
> this net release but it fails miserably to debug anything.  How
> embarrassing.
> 
> The problem is that uiout is being set to NULL in interp_set() because
> that is what is stored in the interpreter structure set up in
> _initialize_gdbtk.

Ugh. I really gotta get my real patch in: I've one patch in gdb that I'm
straightening out now.

Chris, please commit your patch.
Keith

Re: Insight build problem on cygwin (tentative patch enclosed)

[Andrew Cagney]

> -  static const struct interp_procs tk_procs =
> -  {
> -    tk_init,
> -    gdbtk_resume,
> -    gdbtk_suspend,
> -    gdbtk_exec,
> -    gdbtk_prompt_p,
> -    gdbtk_command_loop,
> -  };
> -
> -  interp_add (interp_new ("gdbtk", NULL, NULL, &tk_procs));
> -

FYI,

Removing from _initialize*() is wrong.  Interpreters should only be 
registered in _initialize*() function.

I think the underlying problem is general confusion over the separation 
of powers between interp_add() and interp_init().

BTW, even with that NULL, it worked for me.  Is there something cygwin 
centric going on?

Andrew

Re: Insight build problem on cygwin (tentative patch enclosed)

[Andrew Cagney]

> -  static const struct interp_procs tk_procs =
> -  {
> -    tk_init,
> -    gdbtk_resume,
> -    gdbtk_suspend,
> -    gdbtk_exec,
> -    gdbtk_prompt_p,
> -    gdbtk_command_loop,
> -  };
> -
> -  interp_add (interp_new ("gdbtk", NULL, NULL, &tk_procs));
> -

FYI,

Removing from _initialize*() is wrong.  Interpreters should only be 
registered in _initialize*() function.

I think the underlying problem is general confusion over the separation 
of powers between interp_add() and interp_init().

BTW, even with that NULL, it worked for me.  Is there something cygwin 
centric going on?

Andrew

Re: Insight build problem on cygwin (tentative patch enclosed)

[Christopher Faylor]

On Mon, Feb 17, 2003 at 09:53:22AM -0800, Keith Seitz wrote:
>On Mon, 2003-02-17 at 09:04, Christopher Faylor wrote:
>> I can duplicate this.  I don't know what I was doing when I "tested"
>> this net release but it fails miserably to debug anything.  How
>> embarrassing.
>> 
>> The problem is that uiout is being set to NULL in interp_set() because
>> that is what is stored in the interpreter structure set up in
>> _initialize_gdbtk.
>
>Ugh. I really gotta get my real patch in: I've one patch in gdb that I'm
>straightening out now.
>
>Chris, please commit your patch.

Done.

cgf

Re: Insight build problem on cygwin (tentative patch enclosed)

[Christopher Faylor]

[reply-to set]
On Mon, Feb 17, 2003 at 01:38:02PM -0500, Andrew Cagney wrote:
>>-  static const struct interp_procs tk_procs =
>>-  {
>>-    tk_init,
>>-    gdbtk_resume,
>>-    gdbtk_suspend,
>>-    gdbtk_exec,
>>-    gdbtk_prompt_p,
>>-    gdbtk_command_loop,
>>-  };
>>-
>>-  interp_add (interp_new ("gdbtk", NULL, NULL, &tk_procs));
>>-
>
>FYI,
>
>Removing from _initialize*() is wrong.  Interpreters should only be 
>registered in _initialize*() function.
>
>I think the underlying problem is general confusion over the separation 
>of powers between interp_add() and interp_init().
>
>BTW, even with that NULL, it worked for me.  Is there something cygwin 
>centric going on?

Don't see how it could be.  interp_set does this:

  uiout = interp->interpreter_out;

So, at some point uiout becomes NULL.  I wiped out my old non-working version
so I can't give the specific instance right now but it seems obvious that this
could happen.  If you set interpreter_out to NULL and call interp_set at some
point then uiout will be NULL.

cgf

Re: Insight build problem on cygwin (tentative patch enclosed)

[Christopher Faylor]

[reply-to set]
On Mon, Feb 17, 2003 at 01:42:08PM -0500, Christopher Faylor wrote:
>On Mon, Feb 17, 2003 at 09:53:22AM -0800, Keith Seitz wrote:
>>On Mon, 2003-02-17 at 09:04, Christopher Faylor wrote:
>>>I can duplicate this.  I don't know what I was doing when I "tested"
>>>this net release but it fails miserably to debug anything.  How
>>>embarrassing.
>>>
>>>The problem is that uiout is being set to NULL in interp_set() because
>>>that is what is stored in the interpreter structure set up in
>>>_initialize_gdbtk.
>>
>>Ugh.  I really gotta get my real patch in: I've one patch in gdb that
>>I'm straightening out now.
>>
>>Chris, please commit your patch.
>
>Done.

I've reverted the patch, given Andrew's concerns.

cgf

Re: Insight build problem on cygwin (tentative patch enclosed)

[Christopher Faylor]

On Mon, Feb 17, 2003 at 01:48:19PM -0500, Christopher Faylor wrote:
>[reply-to set]
>On Mon, Feb 17, 2003 at 01:38:02PM -0500, Andrew Cagney wrote:
>>>-  static const struct interp_procs tk_procs =
>>>-  {
>>>-    tk_init,
>>>-    gdbtk_resume,
>>>-    gdbtk_suspend,
>>>-    gdbtk_exec,
>>>-    gdbtk_prompt_p,
>>>-    gdbtk_command_loop,
>>>-  };
>>>-
>>>-  interp_add (interp_new ("gdbtk", NULL, NULL, &tk_procs));
>>>-
>>
>>FYI,
>>
>>Removing from _initialize*() is wrong.  Interpreters should only be 
>>registered in _initialize*() function.
>>
>>I think the underlying problem is general confusion over the separation 
>>of powers between interp_add() and interp_init().
>>
>>BTW, even with that NULL, it worked for me.  Is there something cygwin 
>>centric going on?
>
>Don't see how it could be.  interp_set does this:
>
>  uiout = interp->interpreter_out;
>
>So, at some point uiout becomes NULL.  I wiped out my old non-working version
>so I can't give the specific instance right now but it seems obvious that this
>could happen.  If you set interpreter_out to NULL and call interp_set at some
>point then uiout will be NULL.

The call which sets uiout to NULL is in captured_main, line 559.  Just typing
"insight foo.exe" was enough for me to trigger the problem.  You can also see
it if you type "insight" (which brings up a window) and then do a "File->Open".

cgf

Re: Insight build problem on cygwin (tentative patch enclosed)

[Keith Seitz]

On Mon, 2003-02-17 at 10:54, Christopher Faylor wrote:

> I've reverted the patch, given Andrew's concerns.

Ugh. So we're stuck for a little while... I think I am going to apply my
patch, which includes a nice argv0 hack, but when I address in gdb, I
will be in a position to easily revert this hack.

Stay tuned.
Keith

Re: Insight build problem on cygwin (tentative patch enclosed)

[Rolf Campbell]

Christopher Faylor wrote:
> On Mon, Feb 17, 2003 at 01:48:19PM -0500, Christopher Faylor wrote:
> 
>>[reply-to set]
>>On Mon, Feb 17, 2003 at 01:38:02PM -0500, Andrew Cagney wrote:
>>
>>>>-  static const struct interp_procs tk_procs =
>>>>-  {
>>>>-    tk_init,
>>>>-    gdbtk_resume,
>>>>-    gdbtk_suspend,
>>>>-    gdbtk_exec,
>>>>-    gdbtk_prompt_p,
>>>>-    gdbtk_command_loop,
>>>>-  };
>>>>-
>>>>-  interp_add (interp_new ("gdbtk", NULL, NULL, &tk_procs));
>>>>-
>>>
>>>FYI,
>>>
>>>Removing from _initialize*() is wrong.  Interpreters should only be 
>>>registered in _initialize*() function.
>>>
>>>I think the underlying problem is general confusion over the separation 
>>>of powers between interp_add() and interp_init().
>>>
>>>BTW, even with that NULL, it worked for me.  Is there something cygwin 
>>>centric going on?
>>
>>Don't see how it could be.  interp_set does this:
>>
>> uiout = interp->interpreter_out;
>>
>>So, at some point uiout becomes NULL.  I wiped out my old non-working version
>>so I can't give the specific instance right now but it seems obvious that this
>>could happen.  If you set interpreter_out to NULL and call interp_set at some
>>point then uiout will be NULL.
> 
> 
> The call which sets uiout to NULL is in captured_main, line 559.  Just typing
> "insight foo.exe" was enough for me to trigger the problem.  You can also see
> it if you type "insight" (which brings up a window) and then do a "File->Open".
> 
> cgf
And, at least on my machine, just running "insight" without any 
parameters causes problems.

Re: Insight build problem on cygwin (tentative patch enclosed)

[Christopher Faylor]

On Mon, Feb 17, 2003 at 11:06:50AM -0800, Keith Seitz wrote:
>On Mon, 2003-02-17 at 10:54, Christopher Faylor wrote:
>
>> I've reverted the patch, given Andrew's concerns.
>
>Ugh. So we're stuck for a little while... I think I am going to apply my
>patch, which includes a nice argv0 hack, but when I address in gdb, I
>will be in a position to easily revert this hack.
>
>Stay tuned.

FWIW, I just built a linux version of insight and it dies in the same
way.

cgf

Re: Insight build problem on cygwin (tentative patch enclosed)

[Andrew Cagney]

> [reply-to set]
> On Mon, Feb 17, 2003 at 01:38:02PM -0500, Andrew Cagney wrote:
> >>-  static const struct interp_procs tk_procs =
> >>-  {
> >>-    tk_init,
> >>-    gdbtk_resume,
> >>-    gdbtk_suspend,
> >>-    gdbtk_exec,
> >>-    gdbtk_prompt_p,
> >>-    gdbtk_command_loop,
> >>-  };
> >>-
> >>-  interp_add (interp_new ("gdbtk", NULL, NULL, &tk_procs));
> >>-
> >
> >FYI,
> >
> >Removing from _initialize*() is wrong.  Interpreters should only be 
> >registered in _initialize*() function.
> >
> >I think the underlying problem is general confusion over the separation 
> >of powers between interp_add() and interp_init().
> >
> >BTW, even with that NULL, it worked for me.  Is there something cygwin 
> >centric going on?
> 
> Don't see how it could be.  interp_set does this:
> 
>   uiout = interp->interpreter_out;
> 
> So, at some point uiout becomes NULL.  I wiped out my old non-working version
> so I can't give the specific instance right now but it seems obvious that this
> could happen.  If you set interpreter_out to NULL and call interp_set at some
> point then uiout will be NULL.

I don't know.  Probably didn't use it in anger.

I think the underlying problem is with interp_add().  It shouldn't
even take that ui-out parameter.  Instead the ui-out should be set
using some other mechanism (interp_init()?).

Andrew

PS: Note that the current gdbtk_init() relies on the `going to be
deleted real soon now' init_ui_hook.

Re: Insight build problem on cygwin (tentative patch enclosed)

[Keith Seitz]

On Mon, 2003-02-17 at 17:40, Andrew Cagney wrote:

> PS: Note that the current gdbtk_init() relies on the `going to be
> deleted real soon now' init_ui_hook.

And I'll be committing a patch Real Soon Now (TM) to whack init_ui_hook
from insight. :-)

Keith

Re: Insight build problem on cygwin (tentative patch enclosed)

[Rolf Campbell]

Christopher Faylor wrote:
> On Mon, Feb 17, 2003 at 11:06:50AM -0800, Keith Seitz wrote:
> 
>>On Mon, 2003-02-17 at 10:54, Christopher Faylor wrote:
>>
>>
>>>I've reverted the patch, given Andrew's concerns.
>>
>>Ugh. So we're stuck for a little while... I think I am going to apply my
>>patch, which includes a nice argv0 hack, but when I address in gdb, I
>>will be in a position to easily revert this hack.
>>
>>Stay tuned.
> 
> 
> FWIW, I just built a linux version of insight and it dies in the same
> way.
> 
> cgf
I tried out cygwin "gdb-20030218-1", and on my machine, running it as 
"insight -nx" is now usable, but running it without "-nx" still acts the 
same as it has for the past few versions (does nothing).  I checked, and 
I don't have any of the .gdbinit files (or anything that insight tries 
to read on startup).

Re: Insight build problem on cygwin (tentative patch enclosed)

[Keith Seitz]

On Wed, 2003-02-19 at 07:42, Rolf Campbell wrote:
> I tried out cygwin "gdb-20030218-1", and on my machine, running it as 
> "insight -nx" is now usable, but running it without "-nx" still acts the 
> same as it has for the past few versions (does nothing).  I checked, and 
> I don't have any of the .gdbinit files (or anything that insight tries 
> to read on startup).

You don't have a .gdbtkinit/gdbtk.ini? "-nx" suppresses the reading of
.gdbinit/gdb.ini and .gdbtkinit/gdbtk.ini.

You may have to resort to running insight under gdb and setting a break
on exit, inspecting the backtrace to find out why insight isn't
starting.

Keith

Re: Insight build problem on cygwin (tentative patch enclosed)

[Rolf Campbell]

Keith Seitz wrote:
> On Wed, 2003-02-19 at 07:42, Rolf Campbell wrote:
> 
>>I tried out cygwin "gdb-20030218-1", and on my machine, running it as 
>>"insight -nx" is now usable, but running it without "-nx" still acts the 
>>same as it has for the past few versions (does nothing).  I checked, and 
>>I don't have any of the .gdbinit files (or anything that insight tries 
>>to read on startup).
> 
> 
> You don't have a .gdbtkinit/gdbtk.ini? "-nx" suppresses the reading of
> .gdbinit/gdb.ini and .gdbtkinit/gdbtk.ini.
> 
> You may have to resort to running insight under gdb and setting a break
> on exit, inspecting the backtrace to find out why insight isn't
> starting.
> 
> Keith
Here's my hidden home files:

$ ls -1d ~/.*
/home/rcampbell/./
/home/rcampbell/../
/home/rcampbell/.Xresources
/home/rcampbell/.bash_history
/home/rcampbell/.bashrc
/home/rcampbell/.emacs.d/
/home/rcampbell/.emacs.el
/home/rcampbell/.emacs.elc
/home/rcampbell/.inputrc
/home/rcampbell/.ssh/

I don't have a copy of insight that has debug symbols in it, so I can't 
run it under gdb.  And I'm not in a position right now to download the 
source and compile that.  I did post an strace of a run a while back though.

Re: Insight build problem on cygwin

[Keith Seitz]

On Wed, 2003-02-19 at 07:42, Rolf Campbell wrote:

> Here's my hidden home files:
>
> $ ls -1d ~/.*
> /home/rcampbell/./
> /home/rcampbell/../
> /home/rcampbell/.Xresources
> /home/rcampbell/.bash_history
> /home/rcampbell/.bashrc
> /home/rcampbell/.emacs.d/
> /home/rcampbell/.emacs.el
> /home/rcampbell/.emacs.elc
> /home/rcampbell/.inputrc
> /home/rcampbell/.ssh/
>I don't have a copy of insight that has debug symbols in it, so I
>can't run it under gdb. And I'm not in a position right now to download
>the source and compile that. I did post an strace of a run a while back
>though.

For giggles, can you search your drives for "gdbtk.ini", ".gdbtkinit",
".gdbinit", and "gdb.ini"? There must be something going on with
preferences.

When you start up insight -nx, open a Console Window and type "tk set
::env(HOME)", what does it return? Is there a startup file in that
directory?

Keith

Re: Insight build problem on cygwin

[Rolf Campbell]

Keith Seitz wrote:
> On Wed, 2003-02-19 at 07:42, Rolf Campbell wrote:
> 
> 
>>Here's my hidden home files:
>>
>>$ ls -1d ~/.*
>>/home/rcampbell/./
>>/home/rcampbell/../
>>/home/rcampbell/.Xresources
>>/home/rcampbell/.bash_history
>>/home/rcampbell/.bashrc
>>/home/rcampbell/.emacs.d/
>>/home/rcampbell/.emacs.el
>>/home/rcampbell/.emacs.elc
>>/home/rcampbell/.inputrc
>>/home/rcampbell/.ssh/
>>I don't have a copy of insight that has debug symbols in it, so I
>>can't run it under gdb. And I'm not in a position right now to download
>>the source and compile that. I did post an strace of a run a while back
>>though.
> 
> 
> For giggles, can you search your drives for "gdbtk.ini", ".gdbtkinit",
> ".gdbinit", and "gdb.ini"? There must be something going on with
> preferences.
> 
> When you start up insight -nx, open a Console Window and type "tk set
> ::env(HOME)", what does it return? Is there a startup file in that
> directory?
> 
> Keith

"tk set ::env(HOME)" -> "/home/rcampbell"
I checked my whole hard-drive, and there where no files of those names.

Re: Insight build problem on cygwin

[Keith Seitz]

On Wed, 2003-02-19 at 14:49, Rolf Campbell wrote:
> "tk set ::env(HOME)" -> "/home/rcampbell"
> I checked my whole hard-drive, and there where no files of those names.

Fudge. I cannot image what the problem is, since this works for me and
several other people.

Let's try one of two things (you pick):
1) I can send you/put up for ftp my copy of the Insight executable
2) You can send me/put up for ftp your copy of the insight executable

(Remind me again -- where did you get insight? The cygwin gdb package
that was released yesterday?)

Keith

Re: Insight build problem on cygwin

[Rolf Campbell]

Keith Seitz wrote:
> On Wed, 2003-02-19 at 14:49, Rolf Campbell wrote:
> 
>>"tk set ::env(HOME)" -> "/home/rcampbell"
>>I checked my whole hard-drive, and there where no files of those names.
> 
> 
> Fudge. I cannot image what the problem is, since this works for me and
> several other people.
> 
> Let's try one of two things (you pick):
> 1) I can send you/put up for ftp my copy of the Insight executable
> 2) You can send me/put up for ftp your copy of the insight executable
> 
> (Remind me again -- where did you get insight? The cygwin gdb package
> that was released yesterday?)
> 
> Keith
Oops, replace "where no files of those names" with "was a gdbtk.ini in 
/home/rcampbell, I deleted it and insight now works fine".  It never 
occured to me to look for a ".ini" file.

Re: Insight build problem on cygwin

[Keith Seitz]

On Wed, 2003-02-19 at 17:05, Rolf Campbell wrote:
> Oops, replace "where no files of those names" with "was a gdbtk.ini in 
> /home/rcampbell, I deleted it and insight now works fine".  It never 
> occured to me to look for a ".ini" file.

Cool. Had me really worried there for a moment. I don't know why we use
gdbtk.ini on windows, either. I think some Nazi management at Cygnus
crammed it down our throats. We really ought to just add some code to
change it to .gdbtkinit or .insightrc...

Keith

Re: Insight build problem on cygwin

[Christopher Faylor]

On Thu, Feb 20, 2003 at 08:18:34AM -0800, Keith Seitz wrote:
>On Wed, 2003-02-19 at 17:05, Rolf Campbell wrote:
>> Oops, replace "where no files of those names" with "was a gdbtk.ini in 
>> /home/rcampbell, I deleted it and insight now works fine".  It never 
>> occured to me to look for a ".ini" file.
>
>Cool. Had me really worried there for a moment. I don't know why we use
>gdbtk.ini on windows, either. I think some Nazi management at Cygnus
>crammed it down our throats. We really ought to just add some code to
>change it to .gdbtkinit or .insightrc...

FWIW, I changed gdb to use .gdbinit instead of gdb.ini a while ago, so
there's some precedent there.

gdb issues a warning if it finds a gdb.ini now.

cgf