From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18336 invoked by alias); 20 May 2003 16:14:49 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 17907 invoked from network); 20 May 2003 16:14:42 -0000 Received: from unknown (HELO monty-python.gnu.org) (199.232.76.173) by sources.redhat.com with SMTP; 20 May 2003 16:14:42 -0000 Received: from smtp.atl.cbeyond.com ([64.238.96.29]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19I9RV-0004aT-IO for gcc@gcc.gnu.org; Tue, 20 May 2003 11:54:21 -0400 Received: from [64.238.96.22] (HELO mail.atl.cbeyond.com) by smtp.atl.cbeyond.com (CommuniGate Pro SMTP 4.0.6) with ESMTP id 28116137; Tue, 20 May 2003 11:54:20 -0400 Received: from [66.180.104.54] (HELO software1) by mail.atl.cbeyond.com (CommuniGate Pro SMTP 4.0.6) with ESMTP id 37525645; Tue, 20 May 2003 11:54:02 -0400 From: "E. Weddington" To: Date: Tue, 20 May 2003 16:15:00 -0000 MIME-Version: 1.0 Subject: Re: MinGW (Was: Re: PROPOSAL: Variation on an Alternate policy for obsoleting targets) CC: gcc@gcc.gnu.org Message-ID: <3EC9FAFE.31473.41B01E6@localhost> Priority: normal In-reply-to: <000001c31e67$5ef5fcf0$3c9fd783@northwood> Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body X-SW-Source: 2003-05/txt/msg01865.txt.bz2 On 19 May 2003 at 17:32, Stephan T. Lavavej wrote: > I'm trying to learn. I've managed to successfully build 3.3 on GNU/Linux, > but haven't been able to build any version of gcc on MSYS/MinGW (whether > MinGW-patched or not). I build a GCC cross for the AVR using MinGW / MSYS with a patch from tarballs (no bootstrap). There are some caveats including a bug in the current MSYS that affects GCC which is still not fixed yet: And unfortunately the patch I use is not a very good one. This biggest issue seems to be finding Windows replacements for fork / exec / kill. With Cygwin, its run-time environment handles these calls, but the down side is that GCC is then linked into the Cygwin DLLs. This is not very useful when distributing a binary installation; I'd rather not have to ship an almost 1M DLL just to cover 3 functions. > > Don't forget about Cygwin and DJGPP, which also produce programs that > > run under Windows. Not that I'm putting down MinGW, of course ;-) > > And Cygwin, well, those applications require the Cygwin DLL to be installed on > the end user's computer (correct me if I'm wrong). It's always seemed to me to > be a good solution if you want to simulate GNU/Linux on a Windows machine, but a > bad solution if you want to create executables that you can distribute to > others. When building other software packages in Cygwin, there is always the switch -mno-cygwin available to disable linking to Cygwin DLLs. *But*, you'll need to make sure that the package is not making any Unix-specific calls for it to work, which unfortunately, GCC has those fork / exec / kill calls. Eric