This is the mail archive of the
mailing list for the Cygwin project.
Re: i686-w64-mingw32-gcc & ntifs.h
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)
Cygwin provides cross-compiler toolchains for each of these three "flavors":
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
> 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.
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
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
mingw.org-based, dwarf2 (like mingw.org official, but patched)
mingw64.sf.net (like mingw.sf.net official, but patched)
Confused, yet? http://tdm-gcc.tdragon.net/start
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple