debugging octave 2.1.71 compiled with gcc 3.4.4 on cygwin

[James R. Phillips]

I have been unable to produce a working version of octave 2.1.71 on cygwin
using gcc 3.4.4, which I believe is consistent with Andy Adler's results.  The
executable hangs before issuing the first user prompt.

Using gdb with an unstripped binary compiled with gcc 3.4.4 tonight, I narrowed
down the point where it is hanging to somewhere at the beginning of the
sysdep_init() routine (sysdep.cc).  If I set breakpoint 1 at sysdep_init,
breakpoint 2 at sysdep.cc:197 (the first open curly bracket), and breakpoint 3
at sysdep.cc:201 (the entry to CYGWIN_init()), it hits breakpoint 2 first, then
1, then hangs before hitting breakpoint 3.  Single stepping after breakpoint 1
indicates that it is doing some C++ string allocation, as source listings show
locations inside gcc 3.4.4 header files.  No idea why that would be since there
are no strings obviously allocated in this routine, at least at the C++ source
level.  Basically, it never even gets to CYGWIN_init().

I'm not familiar enough with gdb to know how to further narrow this down.  I'd
like to supply helpful information to the cygwin gcc maintainer, but I don't
know how.  I suppose I need to interrupt the program execution, and try to pull
out the call stack - but I really don't understand how to get this information
in gdb.

Any suggestions?

Thanks,

Jim Phillips