Dave Korn wrote: > On 23/01/2010 19:02, Christopher Faylor wrote: >>> On 1/23/2010 21:51, Chris Sutcliffe wrote: >>>>> mingw-w64<http://mingw-w64.sourceforge.net/> is a fork of mingw to >>>>> support both win32 and win64. It'll obviously be setup as a cross >>>>> compiler on Cygwin. > >> Does this mean that these are all non-cygwin mingw apps? > > Nope, they are cygwin-based cross development tools.
Except, apparently, the proposed build of gdb -- unless Chris S. was confused: > One question though, is there a point to having gdb? The stdin/stdout > handling is messed up a little due to it being an interactive DOS app > running within Cygwin. It works, but the command line interface can > get a little messy after a while. My concern is this: we (cygwin) definitely need a gcc-4-based mingw cross compiler. On which source tree shall it be based, and who will be "our" maintainer? The proposal on the table is to use the mingw-64 source tree (that is, the gcc/binutils source code as patched by the mingw-w64 project, coupled with THIER patched version of the w32api and mingwrt runtime libs), configured in such a way as to support 32bit $host (*). I was under the impression, until now, that we would be using the mingw.org version of all of that. (*) Never mind the 64bit cross-compiler that the OP also proposed; that's a completely separate issue IMO. Now, from a practical standpoint this doesn't matter to me, so long as it works -- and the object code is interoperable. That is, can I compile a static library using C++ or C from the mingw-w64 project's 32bit compiler, and still use it with the mingw.org compiler? And vice versa? >From a policy standpoint...the mingw community is split, and while there has been talk recently concerning reunification, that's all it has been: talk. The issues appear to be both personal and technical, from my interested but only marginally involved viewpoint: Personal: the mingw-w64 guys are critical of the (perceived) lack of user support form the mingw.org community; while the mingw.org guys are pissed that the w64 fellas have been pushing changes into upstream projects like gcc and binutils that sometimes conflict with the "original" mingw. Technical/Legal: The mingw.org guys are ADAMANT that nothing goes in to the runtime libraries and w32api stuff that is not 100% documented to come from open sources: reference to MSDN webpages, published books, etc. They fear -- and not without reason, IMO -- that the w64 folks are less scrupulous about what they put into their version of the w32api headers and .def files. This technical issue makes any reunification, without a painstaking documentation effort to scrutinize every difference between the w64 files and the mingw.org versions. Do we want to choose sides in this? It looks like we have no choice but to choose, as we need SOMETHING to compile native w32 code, such as setup.exe -- and gcc3 is getting long in the tooth. (Alternatively, we could "let a thousand flowers bloom" and have all three: mingw64-gcc-32bit, mingw64-gcc-64bit, and mingw-gcc-32bit cross compile toolchains in the distro...and cgf was worried about confusion?) Or we could allow the mingw64 64bit toolchain (as the mingw.org guys have no ability to support that anyway), but the mingw.org 32bit one. my 2c. -- Chuck