From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4696 invoked by alias); 11 May 2005 19:15:57 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 4613 invoked from network); 11 May 2005 19:15:50 -0000 Received: from unknown (HELO cgf.cx) (66.30.17.189) by sourceware.org with SMTP; 11 May 2005 19:15:50 -0000 Received: by cgf.cx (Postfix, from userid 201) id 817D813C9F2; Wed, 11 May 2005 15:15:50 -0400 (EDT) Date: Wed, 11 May 2005 19:58:00 -0000 From: Christopher Faylor To: gdb-patches@sources.redhat.com Subject: Re: MinGW build instructions Message-ID: <20050511191550.GB18308@trixie.casa.cgf.cx> Mail-Followup-To: gdb-patches@sources.redhat.com References: <01c55598$Blat.v2.4$baecd3c0@zahav.net.il> <428113E4.9090807@codesourcery.com> <01c5559e$Blat.v2.4$1b76ee60@zahav.net.il> <20050510203127.GA10559@nevyn.them.org> <20050510213821.GA8600@trixie.casa.cgf.cx> <20050510214218.GA8776@trixie.casa.cgf.cx> <01c555f9$Blat.v2.4$330af160@zahav.net.il> <4281B26C.60208@codesourcery.com> <20050511161153.GH10119@trixie.casa.cgf.cx> <01c55659$Blat.v2.4$34414ce0@zahav.net.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01c55659$Blat.v2.4$34414ce0@zahav.net.il> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-05/txt/msg00250.txt.bz2 On Wed, May 11, 2005 at 09:41:35PM +0300, Eli Zaretskii wrote: >> Date: Wed, 11 May 2005 12:11:53 -0400 >> From: Christopher Faylor >> >> You don't have to install 700MB of cygwin to get things working. You >> should be able to get away with just installing the bits that you need + >> the mingw compiler. Or, it is possible that a i686-pc-mingw32-gcc >> wrapper like: >> >> #!/bin/sh >> exec gcc -mno-cygwin "$@" >> >> may "just work" with the cygwin version of gcc. The -mno-cygwin option >> to gcc actually uses the mingw headers and libraries. Unfortunately, >> there is a problem with cygwin-bleedover for libraries, though, so >> you have to be careful not to specify any libraries on the command >> line which exist on cygwin but not in mingw. This is something that >> I keep meaning to fix in gcc/binutils... > >Thanks for the info. > >However, what is needed are precise instructions based on actual >experience. If I were someone who needs for the first time compile a >GNU package on Windows, it would not help me to know that >such-and-such setup ``might just work''. Yes, I know that, Eli. These were hints for someone who might want to try it. They were not intended as step-by-step instructions since, obviously I can't provide those. I thought that maybe they'd be useful for someone who was interested in trying this. >Also, the configuration that you suggest: some part of Cygwin and the >MinGW compiler, will probably suffer from incompatibilities due to >Cygwin file names that the MinGW compiler probably doesn't understand, >symlinks that the utilities such as ln support, but the MinGW compiler >might not, etc. I don't see why. You just install the mingw compiler and put it in your path. There obviously won't be any cygwin symlinks in the mingw compiler tar ball. >I didn't try MSYS, but it sounds that they did resolve these problems >in a more satisfactory manner. I doubt it. MSYS's claim to fame is that you don't have to use the cygwin mount table. AFAIK, it does nothing special with symlinks. Msys would not have problems with cygwin bleed over I mentioned since there wouldn't be any cygwin components. OTOH, as I mentioned, AFAIK all of MSYS's components lag cygwin in terms of bug fixes and frequency of updates. It's odd that you apparently don't like my not being specific enough but then go on to postulate general problems with things that you haven't tried. But, regardless, I was just offering opinions. It seems like my offering information has now gotten me into YA debate. I think I'm learning some kind of lesson here. >So I don't really understand why you don't like their alternative. Is >it known to have some serious problems? How much would you like someone saying "I've got this new version of tools that I've called CFGPP" if the tools were a repackaging of DJGPP with some patches? What if the person involved in CFGPP was occasionally apparently fixing bugs but not pushing them back to DJGPP? How about if the CFGPP web site made no mention of the fact that it was 95% DJGPP with some changes? How about if CFGPP binaries started showing up which played badly with DJGPP and people started asking you to fix DJGPP so that it worked better with CFGPP? How about if people started asking CFGPP questions in the DJGPP mailing lists? These are standard problems with a fork and my reaction, as the project lead for Cygwin, is a typical reaction to a fork. I don't know if MSYS has serious problems. I haven't heard of any but I'm not going to endorse it because I use another alternative. cgf