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 X-Injected-Via-Gmane: http://gmane.org/ To: cygwin AT cygwin DOT com From: Charles Wilson Subject: Re: 1.3.20 Date: Tue, 04 Feb 2003 20:50:52 -0500 Lines: 88 Message-ID: <3E406DFC.8030508@ece.gatech.edu> 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; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet AT main DOT gmane DOT org User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en Jonathan Larmour wrote: > I was building natively on cygwin. This *may*, I repeat *may*, be relevant. I dunno about now, but in the past there have been times when cygwin would build fine on Chris' linux-based cross compiler setup, but wouldn't build natively. (and vice versa, IIRC). >>> I also had to symlink winsup/w32api to the separate w32api package >>> sources. > > 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 Err, kinda. The sources are really set up for building from a CVS checkout -- which pulls the w32api stuff along with it. But, if someone were to try to build from the packaged -src tarballs, they would need to either pull the w32api*-src tarball also, or create the symlink you mention. Perhaps we do need an "Idiot's Guide to Compiling Cygwin". Then again, maybe we don't really WANT a bunch of challenged people compiling cygwin from scratch... 8-> > I didn't think cygwin used cross builds for > releases any more either.) Bzzt. Every cgf-built release, which is to say all of them, are built on a linux box. > > 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? Now hold on -- this is probably my fault. I dunno if the wrapper scripts handle both cases. If they don't, then there are a number of workarounds: #1: don't do that. #2: export PATH=/usr/autotool/stable/bin:${PATH} #3: send me patches to fix the wrappers > 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/ *$//'` Or maybe it ISN'T my fault... > 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. Sure, but cgf can be forgiven for playing the house odds -- the deck is stacked, you know. --Chuck -- 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/