Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sourceware DOT cygnus DOT com Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com From: Chris Faylor Date: Sun, 27 Feb 2000 21:24:44 -0500 To: "Charles S. Wilson" Cc: cygwin AT sourceware DOT cygnus DOT com Subject: Re: Undefined reference to '_ctype_'? Message-ID: <20000227212444.A11989@cygnus.com> Reply-To: cygwin AT sourceware DOT cygnus DOT com References: <20000225132218 DOT 5282 DOT qmail AT web110 DOT yahoomail DOT com> <20000225145103 DOT SM00161 AT KENDALLB> <20000226040630 DOT A21594 AT shell4 DOT ba DOT best DOT com> <20000227154653 DOT A7573 AT cygnus DOT com> <38B9BA99 DOT 5C4B3728 AT ece DOT gatech DOT edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.1.4i In-Reply-To: <38B9BA99.5C4B3728@ece.gatech.edu>; from cwilson@ece.gatech.edu on Sun, Feb 27, 2000 at 07:00:25PM -0500 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 >debugging information. > >> 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 >> problem. >> > >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 works fine. 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. cgf -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com