Undefined reference to '_ctype_'?
Sun Feb 27 21:51:00 GMT 2000
On Sun, Feb 27, 2000 at 07:00:25PM -0500, Charles S. Wilson wrote:
> You make a number of very good points in your recent message, and
>I both sympathize and agree with your stance. However, I am one of
>the folks who sent in a "bash is using 100% CPU" reports with no
>> This week, I have spent considerable time trying to track down the
>> various "bash is taking all of my CPU" problems despite the almost total
>> lack of debugging information offered by any of the people reporting the
>I would have liked to send in debugging info -- but had no idea how to
>do it. If I can't run bash, then I cannot run gdb either. Since the
>native (microsoft-supplied) debugging tools are so poor, and cygwin-gdb
>is not accessible, debugging a bash-related problem is quite a
>challenge. It's possible I suppose to use a mingw-based gdb to debug
>the cygwin-based bash, but I don't have mingw setup on my machine.
My understanding was that, in this case, the problem was not that bash
was inoperable. It was that it was using a lot of CPU time. That's
doesn't mean that it isn't working. Also, AFAICT, gdb should still work
in this scenario even if bash is broken.
Anyway, the way that I debug the DLL is to put gdb and a "working" dll
in the same directory and then use that to debug a broken dll. Since
Windows will find a DLL in the same directory as the executable, this
You can also get debugging output from the strace program.
>Anyway, that's my "excuse". I'm sure that many others were in the same
>boat -- they wanted to help and wanted to provide useful debugging
>info. But the failure (bash) was in the critical path for obtaining
>that info. NOTE to others on the list: please, don't clutter the list
>with me-too messages, even if this description matches your experience.
Well, all you, or anyone, had to do was ask.
Want to unsubscribe from this list?
Send a message to email@example.com
More information about the Cygwin