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 Message-ID: <3E4063D9.3070501@eCosCentric.com> Date: Wed, 05 Feb 2003 01:07:37 +0000 From: Jonathan Larmour User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.2) Gecko/20021203 X-Accept-Language: en-gb, en, en-us MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: 1.3.20 References: <3E3E7DB0 DOT 20102 AT eCosCentric DOT com> <20030203153810 DOT GB20606 AT redhat DOT com> In-Reply-To: <20030203153810.GB20606@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Christopher Faylor wrote: > On Mon, Feb 03, 2003 at 02:33:20PM +0000, Jonathan Larmour wrote: > >>Chris Faylor wrote: >> >>>Besides Pierre's outstanding ntsec problems, are there other issues that >>>would hold up a release? >> >>I just heard you're about to release this and was pointed this way. Can I >>ask you to hold off for a few hours at least? >> >>I've been investigating a problem with building GDB under cygwin (pretty >>much any version - 5.2, 5.3, 5.3.1). It segfaults on startup. > > >>My current theory is that vasprintf for newlib is broken, and needs to >>have the _file field of the FILE * initialised to some value. > > > Hmm. Jason Tishler already tracked down a problem with vasprintf, > AFAIK. It should be in cygwin snapshots. Unfortunately that's an unrelated issue. > Can I suggest, discussing this in the newlib mailing list, if you think > it is a newlib problem? The patch has indeed been submitted there now - no response yet. >>It would be a shame to release a cygwin with a known serious (given the >>effect on GDB) bug. > > 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. I'm sure you wouldn't appreciate bug reports about any GDB failures just because they are on cygwin :-). >>BTW: I think there need to be some decent instructions on building the DLL > >>from source. I had various build failures with the 1.3.19-1 sources, like > >>net.cc not having a declaration of gethostname(), and when doing a make >>install, cygrun.exe failing to link. I didn't bother fixing that. > > > 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. >>I also had to symlink winsup/w32api to the separate w32api package sources. > > Ah, so you are using an older version of gcc. No, the current GCC (3.2) that cygwin's setup.exe lets me download. The reason is this in winsup/configure.in: if test -d $srcdir/w32api; then SUBDIRS="w32api $SUBDIRS" else echo "*** missing w32api directory" 1>&2 exit 1 fi Since cygwin and w32api source packages are distributed separately the test fails. A symlink obviously fixes this once you see that this is what is going on. This should probably be documented rather than trying to make some clever fix to scan directories matching /usr/src/w32api*. Easiest is probably just a note in the FAQ at . 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 (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). 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.) Whatever way, I don't believe your tone was warranted. >>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. It no longer uses the original "cygnus" configure but now autoconf. In particular the following script fragment in configure.in is very new, very bleeding edge (last changed 17th Jan) and very broken :-)... baseargs=`echo " ${ac_configure_args} " | \ sed -e 's/ --no[[^ ]]* / /' \ -e 's/ --c[[a-z-]]*[[= ]][[^ ]]* / /' \ -e 's/ --sr[[a-z-]]*[[= ]][[^ ]]* / /' \ -e 's/ --ho[[a-z-]]*[[= ]][[^ ]]* / /' \ -e 's/ --bu[[a-z-]]*[[= ]][[^ ]]* / /' \ -e 's/ --t[[a-z-]]*[[= ]][[^ ]]* / /' \ -e 's/ -cache-file[[= ]][[^ ]]* / /' \ -e 's/ -srcdir[[= ]][[^ ]]* / /' \ -e 's/ -host[[= ]][[^ ]]* / /' \ -e 's/ -build[[= ]][[^ ]]* / /' \ -e 's/ -target[[= ]][[^ ]]* / /' \ -e 's/ [[^ -][^ ]*] / /' \ -e 's/^ *//;s/ *$//'` The last expression strips unadorned options. This is the cause of the problem - it considers the prefix argument to be some sort of unadorned option. As a consequence baseargs gets set incorrectly causing problems further down the line when configuring subdirectories. So again I don't think your tone was warranted - this isn't me being a dumb user with some basic autoconf misunderstanding - it's a specific problem with very recent changes in a customisation of configure.in. I will follow this up on binutils and gdb-patches lists as they claim responsibility for top level configure. >>'Twould be good if this stuff was documented just in a README.build or >>something. > > > 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 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. Jifl -- eCosCentric http://www.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/