This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Need input on packaging mingw-w64 for Cygwin


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]