1.3.20
Jonathan Larmour
jifl@eCosCentric.com
Wed Feb 5 22:13:00 GMT 2003
> 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
>>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)."
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
> you.
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
>>>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 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
>>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.
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
>>environments.
>
> I think my observation still stands. You made some beginner mistakes,
> the most fundamental being that you apparently didn't read the
> documentation.
<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.
Jifl
--
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
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
More information about the Cygwin
mailing list