Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Date: Tue, 4 Feb 2003 23:34:07 -0500 From: Christopher Faylor To: cygwin AT cygwin DOT com Subject: Re: 1.3.20 Message-ID: <20030205043407.GB4959@redhat.com> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: <3E3E7DB0 DOT 20102 AT eCosCentric DOT com> <20030203153810 DOT GB20606 AT redhat DOT com> <3E4063D9 DOT 3070501 AT eCosCentric DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E4063D9.3070501@eCosCentric.com> User-Agent: Mutt/1.5.1i 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 doesn't work, although >>>--prefix= 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= syntax by default. This is true, but --prefix 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 >>". > >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/