64 bit Cygwin target and _WIN64

Christopher Faylor cgf-use-the-mailinglist-please@cygwin.com
Wed Jul 18 17:30:00 GMT 2012


On Wed, Jul 18, 2012 at 01:10:11PM -0400, Christopher Faylor wrote:
>On Wed, Jul 18, 2012 at 05:09:51PM +0200, Corinna Vinschen wrote:
>>On Jul 18 11:00, Christopher Faylor wrote:
>>> On Wed, Jul 18, 2012 at 04:42:02PM +0200, Corinna Vinschen wrote:
>>> I really don't see why the Mingw64 project should have to accommodate
>>> Cygwin.  Maybe if we put a #define _WIN64 in a Cygwin header, I'd feel
>>> slightly better about this but I don't see why another project should
>>> have to change to accommodate us.  Should they also have defines for
>>> Wine and ReactOS?  That doesn't seem like the right way to go.
>>
>>They are happy to accomodate us.  Some of the problems we have are
>>shared with the wine project, so the advantages are partially mutual.
>>Mingw64 has already a header called _cygwin.h which is indirectly
>>included if a Cygwin project includes any Windows header.  It's no
>>problem to add
>>
>>  #ifdef __CYGWIN64__
>>  #define _WIN64
>>  #endif
>>
>>to this file.
>
>Oh boy.  Another project like newlib where we have to get permission to
>make Cygwin-specific changes.

Sorry.  My sarcasm there did not explain my actual concern.

I think that the more we can isolate Cygwin decisions to the
winsup/cygwin and directly related directories, the better off we are.

We don't have many problems adding stuff to newlib until someone wants a
few tweaks for RTEMS or something similar.  And, sure, they are not a
big deal.  They take time, though, and force us to worry about concerns
that are not directly Cygwin related.

We probably wouldn't have many issues getting code into MinGW* either.
But, there is a whole other set of developers whose buyin is required
for changes.  They are probably very reasonable people but, if we can
help it, I'd rather opt for not having to gain consensus from people who
don't have Cygwin as their priority.



More information about the Cygwin-developers mailing list