Subject: Re: b20.1: build question
From: [email-masked] (Christopher Faylor)

2 Jan 1999 01:06:20 -0800
Message-ID: <[email-masked]>
References: <179AA48D1741D211821700805FFE241873CA8B@HQMAIL02>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
To: Kevin Schnitzius <[email-masked]>
Cc: [email-masked]

On Thu, Dec 31, 1998 at 07:40:17PM -0500, Kevin Schnitzius wrote:
>> From: [email-masked] [mailto:[email-masked]]
>> Sent: Thursday, December 31, 1998 11:26 AM
>> To: [email-masked]
>> Subject: Re: b20.1: build question
>> 
>> In article 
>> <179AA48D1741D211821700805FFE241873CA83.cygnus.gnu-win32@HQMAIL02>,
>> Kevin Schnitzius <[email-masked]> 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
"[email-masked]" with one line of text: "help".