From: cgf AT cygnus DOT com (Christopher Faylor) Subject: Re: b20.1: build question 2 Jan 1999 01:06:20 -0800 Message-ID: <19990101210030.F27648.cygnus.gnu-win32@cygnus.com> References: <179AA48D1741D211821700805FFE241873CA8B AT HQMAIL02> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii To: Kevin Schnitzius Cc: gnu-win32 AT cygnus DOT com On Thu, Dec 31, 1998 at 07:40:17PM -0500, Kevin Schnitzius wrote: >> From: cgf AT cygnus DOT com [mailto:cgf AT cygnus DOT com] >> Sent: Thursday, December 31, 1998 11:26 AM >> To: gnu-win32 AT cygnus DOT com >> Subject: Re: b20.1: build question >> >> In article >> <179AA48D1741D211821700805FFE241873CA83 DOT cygnus DOT gnu-win32 AT HQMAIL02>, >> Kevin Schnitzius wrote: >> > >> >On my NT4.0 box, should I be able to: >> >3a. Muck about with the newlib configuration to get it to work. >> >> This is the third mention I've seen of people having problems with >> configuring newlib. >> >> The annoying thing is that every one of them mentions that there are >> problems but no one has yet reported what the problems are. >> >> If someone would like to report *exactly* what the problem with newlib >> configure might be, I'd be happy to look into getting it fixed. > >If you use a subdirectory for the src and obj directories, you'll see this >problem. For example, when I used /cygwin/src and /cygwin/obj, the newlib >configure script tanked. When I moved them to /src and /obj, I was at >least able to build. Ok. This is slightly more information but I have no idea what "tanked" means. Since you've already experienced the problem and undoubtedly have seen an error message of some sort, why not let us know what it is? That way I might actually be able to debug the problem without trying to duplicate your setup exactly. I hope that anyone reading this will see this as a general plea for *specific* reporting of error messages. It is remarkably inefficient for us to have to go through the effort of attempting to set things up to duplicate every reporter's setup when we could actually be getting information that might allow us to fix problems without going to this effort. What is required are the *specific* errors that are appearing and possibly even any other surrounding output. cygcheck output would also be nice. Imagine that you were bringing your car into the shop. The mechanic would ask you what specifically was wrong. If you respond "It doesn't run right." that's almost no information. You'd probably be probed for more details. If you respond "It doesn't run right when I go 57 MPH" that's slightly more information but you're still expecting the mechanic to take the car out and hopefully notice whatever problem you are seeing. If you report that "The car makes a strange pinging sound in the left front when I go 57 MPH or more" then you might actually have provided enough information for the mechanic to diagnose and fix the problem without having to take the car out for two test drives. In this case, you, and other people are reporting bugs to what are essentially volunteers. A mechanic would actually charge you for the time it took to road test your car. We don't do that. We try to fit the activity of supporting the gnu-win32 mailing list into full-time jobs. That means that if you want help debugging a problem you should try to help out as much as possible by doing as much up-front work as you can. From a purely pragmatic point of view, anyone who does this will be more likely to be helped because it is possible that solutions to problems will be obvious with minimal effort on our part. >I'm currently seeing an access fault in fhandler_base::de_linearize() >but when I attach gdb, it doesn't show up. Arrgh. This looks like >maybe a stack problem. Any one else run into this? (NT4.0, B20.1 >tools and src). That's a symptom of more than one cygwin1.dll on your system. Just keep the latest one around. cygcheck should tell you more about this. -chris - For help on using this list (especially unsubscribing), send a message to "gnu-win32-request AT cygnus DOT com" with one line of text: "help".