This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 1.3.20

On Wed, Feb 05, 2003 at 01:07:37AM +0000, Jonathan Larmour wrote:
Christopher Faylor wrote:
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 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)."
Yes I tried using CVS at first. I have to confess I didn't notice the _absence_ of this particular problem when I tried that route (there still being some of the other issues I mentioned, and this being _before_ I tried the source packages). That I take responsibility for. However the cygwin1.dll that was built was useless resulting in an application error immediately on starting any application using it, even when attempting to debug it from within GDB, so I gave up - I don't have the tools for such issues.

But if you knew about the problem, perhaps you could have given a more constructive reply than "That's how it works. If it doesn't build for some reason, that's a bug." And if the w32api package *does* have known bugs preventing it being usable for builds, why not release it?

[snip cygrun stuff, apart from:]
(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
cygrun.c references stderr, which from the newlib headers gives a reference to _impure_ptr. My guess is you didn't happen to build natively since this bug was introduced (whenever that was) since CC flags would differ greatly between native and cross builds.

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
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 configure failed very late on in the build in w32api, not the top level, well after most other things had built successfully. It's a reasonable first guess that the problem was there.

But I wasn't even *advocating* fixing it (although I will do now), mostly since I thought it only affected cygwin. I was advocating documenting it simply as a known limitation with a trivial workaround. Instead I tracked it down, which by luck happens to be better for all in the long run.

Your first guess was even more wrong: accusing me of knowing nothing about autoconf. And it was even less constructive.

The bottom line is that you told me that you had no intention of actually
getting involved in cygwin development.
Now who's quoting "private" e-mail.

>  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.
Don't be so quick to accuse. I had already read that. I used CVS and it sucked. I backtracked to the sources of the most recent stable release, all of a week old. Are you implying "stable" releases are *that* unsupported?

> 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.
Again, don't be so quick to accuse. Yes I searched the cygwin mailing list. No mention of that that I could see. Looking again I still can't. I see a thread about the "cyg" prefix specifically, and python, and no public request from you for feedback on tclsh84 naming.

> Just pop in raise
an issue (regardless of whether it had already been raised) and pop out again.
No need to get overly involved.
Please show me exactly which specific issue I raised that has appeared before on the cygwin list.

eCos users don't want to know anything about Cygwin and eCos developers
want to know only the bare minimum.
You can be sure that the helpfulness, constructiveness and politeness of any responses to mails would be bound to affect whether people want to get involved in Cygwin development or not.

Most open source projects welcome bug reports, rather than get responses with aspersions and abuse.

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.
I think you may be being sensitive if my original mails were "criticism". And if you don't want suggestions on anything ever, why do you read the cygwin list *at all*?

> In my book, you don't get to do that unless you
have taken the time to familiarize yourself with what's going on.
On the contrary, I believe users shouldn't have to spend aeons fighting problems, and looking for non-existant documentation, especially when it will be beyond many of them. If I encounter problems in (just one week old!) sources, so would they. I'd quite like to prevent that. I did it to try and help - *I* didn't have any more problems. *I* didn't need the help. In fact, you were berating me earlier for *not* posting earlier to the cygwin list. Make up your mind!

Instead I fixed a moderately obscure bug you were going to hit yourself sooner rather than later, and now you make me resent the fact I did. (Yes, the patch is checked in to newlib now).

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
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.
It would be messy to document both. Both are nevertheless supported, and both have always worked until a few weeks ago in CVS evidently. But I was only advocating documenting the limitation - I thought that was nice, simple and sufficient (although I thought the problem was restricted to building cygwin), and didn't need a long e-mail exchange.

What would still be worth documenting is needing to link the w32api source package into the winsup directory if using the source packages rather than CVS. It only requires a single sentence in the FAQ section I already cited explicitly.

Otherwise why do you even bother giving people sources if you only intend them to use (the occasionally broken) CVS?

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
I think my observation still stands.  You made some beginner mistakes,
the most fundamental being that you apparently didn't read the
<pantomime>Oh yes I did</pantomime>. The whole point was commenting on what should be added to help just a little!

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.
By that argument, you would fail the same test. You made as many, no, more incorrect assumptions about what was going on. Sorry.

eCosCentric <>
--[ "You can complain because roses have thorns, or you ]--
--[ can rejoice because thorns have roses." -Lincoln ]-- Opinions==mine

Unsubscribe info:
Bug reporting:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]