X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-2.0 required=5.0	tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,RCVD_IN_DNSWL_LOW,TW_JL
X-Spam-Check-By: sourceware.org
Message-ID: <4E52D5C5.4060106@cwilson.fastmail.fm>
Date: Mon, 22 Aug 2011 18:18:45 -0400
From: Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>
Reply-To: Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>
User-Agent: Mozilla/5.0 (Windows NT 5.2; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: i686-w64-mingw32-gcc & ntifs.h
References: <svliuq67y2 DOT fsf AT smsv2-L DOT wtc DOT algo>	<4E4D9487 DOT 4080103 AT users DOT sourceforge DOT net>	<sv39gy47h5 DOT fsf AT smsv2-L DOT wtc DOT algo>	<4E4E38B9 DOT 9010803 AT users DOT sourceforge DOT net>	<20110819120044 DOT GA2506 AT calimero DOT vinschen DOT de>	<svr54h2ql5 DOT fsf AT smsv2-L DOT wtc DOT algo>	<4E4F08D3 DOT 3060007 AT users DOT sourceforge DOT net>	<CAEwic4YRYiOPP+6AQH_UrnO0pTpc6xYTZrV4bC-esAACXxCOaQ AT mail DOT gmail DOT com>	<87fwkunsna DOT fsf AT gnu DOT org> <4E5229ED DOT 9050805 AT users DOT sourceforge DOT net> <svfwktf8v4 DOT fsf AT smsv2-L DOT wtc DOT algo>
In-Reply-To: <svfwktf8v4.fsf@smsv2-L.wtc.algo>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

On 8/22/2011 5:13 PM, Sam Steingold wrote:
> PS. Why are cygwin/mingw and msys/mingw so different?

They are not different. In fact, 'cygwin/mingw.org' and 'msys/mingw.org'
are identical (except for the emulation environment under which they
run: msys vs. cygwin).

You're confused by the existence of the separate "mingw64" project.

There are three different "flavors" of mingw-ish compilers:
  1. mingw.org (32bit only)

  2. mingw64.sf.net
     a) 32bit
     b) 64bit

Cygwin provides cross-compiler toolchains for each of these three "flavors":

1)  i686-pc-mingw32-gcc
2a) i686-w64-mingw32-gcc
2b) x86_64-w64-mingw32-gcc

The mingw.org compilers, cygwin's mingw.org-target cross compiler, (and
cygwin's own native compilers) all use the "mingwrt" MinGW runtime
library (linkage to the MS C runtime librar[ies] and headers, plus
special additions like libmingwex, etc *), and the "w32api"
headers/import libs for access to the Windows facilities (windows.h,
libwinspool.a, etc **).

* Think "<stdio.h>", "<conio.h>", "<strings.h>" and msvcrt.dll
** Think "<windows.h>", "<ddk/ntapi.h>", libkernel.a...

The mingw64.sf.net compilers and cygwin's mingw.sf.net-target cross
compilers use an independently developed implementation of both a
"mingw" runtime and Win32 API headers/import libs.  However, mingw64
makes no distinction between stuff that is strictly Win32 API-related
(like windows.h or libwinspool.a), and stuff that is mingw-compiler
related (like libmingwex.a).  Instead, they distinguish between
"headers" and "libs".  So, they have "mingw-w64-crt" (the libs), and
"mingw-w64-headers".

> which is "correct"? which is "better"?

Depends on what you want to do.  The "gcc" is mostly the same; both
flavors are derived from the same upstream source.  The difference is
mainly:

1) Exception handling
  a) mingw.org uses "dwarf2 exception handling". MUCH faster (**wrt
exceptions**), but not compatible with certain kinds of windows programming.

  b) mingw64.sf.net uses "sjlj exception handling".  This is slower, but
always works.  They use it because of the compatibility issue above, but
also because sjlj just plain can't work in 64bit mode.  Since they want
both their 32bit and 64bit compilers to use the same flavor, they're
stuck with sjlj.  They are working on a SEH-based implementation for
gcc; once that is complete, I expect that both mingw.org and
mingw64.sf.net will probably switch to using SEH.

2) The runtime libs and w32api used. Explained above. mingw64's
implementation is more complete -- but that's a relative term. You can
do quite a bit with mingw.org's version...like, the entire cygwin
distribution...

3) bitdepth.  Should be obvious, but: mingw.org is 32bit only.
mingw64.sf.net supports both 32bit and 64bit (but usually with separate
toolchains; multilib is supported, but not encouraged).

> will they ever converge?

The mingw-ish bits (scattered between mingw-w64-headers and
mingw-w64-crt) could be shared between the two projects.  It would just
take a bit of work to tease them out, given that the file structure and
build machinery of the two projects are so different.

OTOH, the w32api stuff would require just as much work (per file, and
there are a LOT more w32api files than mingwrt ones), but there's also a
bit of a spat concerning licensing, provenance tracking, and the like.
Both sides think they are right, and the other side is taking foolish
risks or being needlessly paranoid.  Search the projects' mailing list
archives and discuss the issues there, NOT here. We don't want to
(re)start that old flame war on the cygwin lists.

So...while there have been small movements toward a rapprochement, odds
are pretty low.



BTW, there is yet another flavor of mingw-ish compiler, produced by a
fourth party: the "TDM" compilers.  It's a repackaging of the mingw.org
and mingw64.sf.net compilers, with local customizations. It comes in
three editions:
  mingw.org-based, dwarf2 (like mingw.org official, but patched)
  mingw.org-based, sjlj
  mingw64.sf.net          (like mingw.sf.net official, but patched)
Confused, yet?  http://tdm-gcc.tdragon.net/start


--
Chuck

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple