i686-w64-mingw32-gcc & ntifs.h
Mon Aug 22 23:09:00 GMT 2011
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?
> 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
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
>> 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
> 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.
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
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
> 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).
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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 196 bytes
Desc: OpenPGP digital signature
More information about the Cygwin