This is the mail archive of the
mailing list for the Cygwin project.
- From: Jonathan Larmour <jifl at eCosCentric dot com>
- To: cygwin at cygwin dot com
- Date: Wed, 05 Feb 2003 22:13:20 +0000
- Subject: Re: 1.3.20
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
On Wed, Feb 05, 2003 at 01:07:37AM +0000, Jonathan Larmour wrote:
To quote from the FAQ:
Christopher Faylor wrote:
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.
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.
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.
"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)."
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:]
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.
(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
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.
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 '='.
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
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.
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
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?
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
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.
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
Please show me exactly which specific issue I raised that has appeared
before on the cygwin list.
an issue (regardless of whether it had already been raised) and pop out again.
No need to get overly involved.
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.
eCos users don't want to know anything about Cygwin and eCos developers
want to know only the bare minimum.
Most open source projects welcome bug reports, rather than get responses
with aspersions and abuse.
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*?
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
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!
have taken the time to familiarize yourself with what's going on.
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).
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.
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.
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
Otherwise why do you even bother giving people sources if you only intend
them to use (the occasionally broken) CVS?
<pantomime>Oh yes I did</pantomime>. The whole point was commenting on
what should be added to help just a little!
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
By that argument, you would fail the same test. You made as many, no, more
incorrect assumptions about what was going on. Sorry.
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.
eCosCentric http://www.eCosCentric.com/ <info@eCosCentric.com>
--[ "You can complain because roses have thorns, or you ]--
--[ can rejoice because thorns have roses." -Lincoln ]-- Opinions==mine
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html