X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-2.5 required=5.0	tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,TW_JL
X-Spam-Check-By: sourceware.org
Message-ID: <4E52E193.7090706@users.sourceforge.net>
Date: Tue, 23 Aug 2011 07:09:07 +0800
From: JonY <jon_y AT users DOT sourceforge DOT net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080213 Thunderbird/2.0.0.12 Mnenhy/0.7.5.0
MIME-Version: 1.0
To: cygwin AT cygwin DOT com,
        "mingw-w64-public AT lists DOT sourceforge DOT net" <mingw-w64-public AT lists DOT sourceforge DOT net>
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> <4E52D5C5 DOT 4060106 AT cwilson DOT fastmail DOT fm>
In-Reply-To: <4E52D5C5.4060106@cwilson.fastmail.fm>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9A6F7FD2C4E0A3460C5A7C27"
X-IsSubscribed: yes
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

--------------enig9A6F7FD2C4E0A3460C5A7C27
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 8/23/2011 06:18, Charles Wilson wrote:
> On 8/22/2011 5:13 PM, Sam Steingold wrote:
>> PS. Why are cygwin/mingw and msys/mingw so different?
>=20
> 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).
>=20
> You're confused by the existence of the separate "mingw64" project.
>=20
> There are three different "flavors" of mingw-ish compilers:
>   1. mingw.org (32bit only)
>=20
>   2. mingw64.sf.net
>      a) 32bit
>      b) 64bit
>=20
> Cygwin provides cross-compiler toolchains for each of these three "flavor=
s":
>=20
> 1)  i686-pc-mingw32-gcc
> 2a) i686-w64-mingw32-gcc
> 2b) x86_64-w64-mingw32-gcc
>=20
> 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 **).
>=20
> * Think "<stdio.h>", "<conio.h>", "<strings.h>" and msvcrt.dll
> ** Think "<windows.h>", "<ddk/ntapi.h>", libkernel.a...
>=20
> 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".
>=20

The difference also make it hard to build Cygwin off of mingw-w64
headers/crt, since the Cygnus tree has always been using the mingw.org
flavor.

>> which is "correct"? which is "better"?
>=20
> 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:
>=20
> 1) Exception handling
>   a) mingw.org uses "dwarf2 exception handling". MUCH faster (**wrt
> exceptions**), but not compatible with certain kinds of windows programmi=
ng.
>=20
>   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.
>=20

You mean dw2 not working on win64, but yes, there is some SEH support
for win64 already, but not much yet for win32 afaik.

> 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...
>=20

mingw-w64 mainly serves XP and later, so if you want to support earlier
versions of Windows, you'll need to try your luck, or just use mingw.org.

mingw-w64 also imports works from ReactOS and Wine, while this leads to
a more complete API set, it is also hard to argue that its completely
public domain like mingw.org, so there is that licensing preference for
the user.

> 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).
>=20

The multilib gcc builds require some manual dexterity to get it right
without messing up target support libs install, since all DLLs want to
go into bindir regardless of bitness, I'm not sure if they fixed this in
gcc trunk.


--------------enig9A6F7FD2C4E0A3460C5A7C27
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)

iEYEARECAAYFAk5S4ZMACgkQp56AKe10wHfd9wCgkVqh7uJSv2dhhyyDABF/zvXm
7d4An0Vaxj52Vy7PTHdCL4PB8jOb2xM+
=l79t
-----END PGP SIGNATURE-----

--------------enig9A6F7FD2C4E0A3460C5A7C27--