Re: 1.3.20

[Christopher Faylor <cgf at redhat dot com>]

On Wed, Feb 05, 2003 at 01:07:37AM +0000, Jonathan Larmour wrote:
>Christopher Faylor wrote:
>>It's a shame that you were discussing this on the ecos list for days
>>without notifying anyone in cygwin land.
>
>If you mean that you saw my post on the ecos list at the end of last week, 
>at that point we were not yet sure if it was GDB problem or a cygwin 
>problem although we had our suspicions. It took a while to ascertain it 
>was definitely a cygwin (specifically newlib inside cygwin) problem.

To quote from your ecos-discuss email:
"It's a problem with the current cygwin DLL."

However, this discussion did happen on Saturday so it was unfair of me
to accuse you of discussing it "for days".

>>Give me a friggin' break.  "/path/to/source/configure; make".  That's how
>>it works.  If it doesn't build for some reason, that's a bug.  Given
>>that I'm producing snapshots from the source base on a regular basis,
>>however, it's a strange bug.
>
>I was building natively on cygwin. I can only report what I see. For the 
>net.cc problem I am slightly mystified why you are indignant. It turns out 
>I now see it was you that fixed this problem in CVS on 11th Jan in 
>winsock2.h. As I said I was building from the 1.3.19-1 sources so this 
>failure should surely not be a surprise to you.
>
>What seems odd is that from the cvs log you fixed this before the cygwin 
>1.3.19 release, but that's easily explained: someone forgot to also 
>release the corrected w32api package. Since this bug (minor though it is) 
>prevents cygwin building, I encourage the person responsible (you or 
>whoever) to do so, so that builds work for the net.

To quote from the FAQ:

"As of this writing, you need to install at least the cygwin source 
package and the w32api source package.

It is possible that the cygwin source package may require a newer 
version of the w32api package since the release of the packages is not
always in lock step (another reason to just use CVS)."

>For the failing build of cygrun.exe, I see in the current CVS that Corinna 
>moved it to the testsuite, so that's no longer a problem

Right.  It's no longer a problem.  The fact is, that you *know* that it
makes sense to check CVS for fixes before reporting a problem.

I confess that I actually thought you were working from CVS since you
were responding to a thread entitled "1.3.20" and working from the
"1.3.19" sources wouldn't make much sense.

>(And indeed there was a problem: cygrun is a mingw app, but used $(CC)
>which defines all the cygwin include path headers before any of the mingw
>ones. This resulted in an unresolved reference to _impure_ptr).

That's only a problem if something actually used a variable which
referenced _impure_ptr.  I don't know why this worked for me and not for
you.

Now that you mention it, I believe that Corinna had similar issues
rebuilding cygrun.  I started to modify the Makefile.in then she
suggested moving everything to the testsuite directory.  So that's what
we did.

>I don't see how you could have built it in the same environment without
>hitting that problem.  Unless you change something in your environment
>like overriding $(CC).  I didn't think cygwin used cross builds for
>releases any more either.)

I build everything I release on linux but I rebuild cygwin on windows
quite frequently.

>>>Oh, and configuring with --prefix <blah> doesn't work, although 
>>>--prefix=<blah> does :-).
>>
>>What in the world, are you talking about?  Are you completely unfamiliar
>>with autoconf?  Do you think that cygwin has some special version of
>>configure?
>
>If you're referring to autoconf always preferring to document the 
>--prefix=<blah> syntax by default. This is true, but --prefix <blah> has 
>always worked elsewhere, and is meant to work - autoconf normally goes to 
>great lengths to support it - and I just use it out of habit as bash 
>didn't use to do filename completion after '='.
>
>But anyway, I initially thought the problem was some failing customisation 
>in w32api's configure scripts because that's where the build failed with a 
>broken configure line. However now I see there have evidently been many 
>recent changes to the top level configure files since both gcc 3.2.1 and 
>gdb 5.3 which are both recent releases which worked with this syntax.

And, as you imply, the cygwin project does not control the top-level
configure.  Rather than assuming that we're using something other than
autoconf, or that we're somehow customizing configure, it would behoove
you to do a little more research before reporting bugs.

The bottom line is that you told me that you had no intention of actually
getting involved in cygwin development.  Your modus operandi (and stated
goal) was to pop in and pop out again.  You seem to have had problems which
would have been helped by reading the FAQ.  You have reported package problems
on the same day that I was publicly asking for feedback on the tcl84 naming
conventions.  Did you respond to that thread?  Nope.  Just pop in raise
an issue (regardless of whether it had already been raised) and pop out again.
No need to get overly involved.

eCos users don't want to know anything about Cygwin and eCos developers
want to know only the bare minimum.

I completely understand why that would be so but I don't necessarily
have to live with it gladly if you are going to take the pop in/out
occasions as an opportunity to offer criticism or suggestions on how
things should be done.  In my book, you don't get to do that unless you
have taken the time to familiarize yourself with what's going on.

>>Not gonna happen.  As is so often the case in cygwin land, you've
>>fallen into the trap of thinking "it must be hard, why don't they help
>>me" rather than "it works this way on unix, something must be broken
>><in my installation>".
>
>No.  I prefer not to let people hit the same problems over and over
>again.  *I* am perfectly capable of solving the problems, but other
>people aren't.  And indeed *I* already had solved the problems for
>myself.

I'm not sure what, exactly, needs to be documented further.  Personally,
I wasn't aware that it was possible to use spaces rather than equals
after options in configure.  As you mentioned, configure --help
certainly doesn't offer this possibility either in the "cygnus" version
or the "autoconf" version.

If this is something that urgently needs to be documented, then it seems
like the people responsible for the top-level changes would be the
ones to do it.  I hope you'll be lobbying for this when you submit
your patches.

>I would be grateful in future if you could remember that some people
>reporting problems are not dumb, are perfectly capable of solving these
>problems, and are prepared to help fix them for the benefit of others
>in future.  And not all problems are intrinsically the fault of the
>reporter just because they aren't the experiences in different
>environments.

I think my observation still stands.  You made some beginner mistakes,
the most fundamental being that you apparently didn't read the
documentation.  And, secondarily, you were offering suggestions without
fully understanding what was going on.  Both are classic for cygwin
and for many other open source mailing lists.

I made some erroneous assumptions, too, and my tone was more frenzied
than was warranted.  I apologize for both.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/