This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: 64 bit Cygwin target and _WIN64
- From: Earnie Boyd <earnie at users dot sourceforge dot net>
- To: cygwin-developers at cygwin dot com
- Date: Wed, 18 Jul 2012 08:36:22 -0400
- Subject: Re: 64 bit Cygwin target and _WIN64
- References: <20120718110302.GA23825@calimero.vinschen.de>
On Wed, Jul 18, 2012 at 7:03 AM, Corinna Vinschen wrote:
> Hi guys,
>
>
> Here's a problem I need feedback for.
>
> I'm currently working on making Mingw64 headers 64 bit Cygwin aware.
> One, IMHO pretty tough problem is the definition of _WIN64.
>
> A Cygwin-targeting gcc does not define WIN32, _WIN32, __WIN32 and
> __WIN32__ by default. The original reason is that we had (and probably
> still have) a lot of projects, which test for _WIN32 one way or the
> other to decide if a POSIX or a Windows function should be called,
> the latter typically to be avoided.
>
> Now comes the time for _WIN64. _WIN64 is used a *LOT* inside of the
> Mingw64 headers to distinguish type definitions which differ from the
> 32 bit version, or to declare functions which only exist on 64 bit
> machines, stuff like that.
>
Is it needed always or just during compilation of Cygwin? (but read on
before answering)
> There are a couple of ways to help us along with this problem:
>
> 1. Replace all
>
> #ifdef _WIN64
>
> with
>
> #if defined (_WIN64) || defined (__CYGWIN64__)
>
Ugly, what happens now with _WIN32 headers?
> 2. In a core Mingw64 header:
>
> #if defined (_WIN64) || defined (__CYGWIN64__)
> #define _WINX64
> #endif
>
> Then replace all `#ifdef _WIN64' with `#ifdef _WINX64'.
>
I don't see this happening; too easy to break.
> 3. In a core Mingw64 header:
>
> #ifdef __CYGWIN64__
> #define _WIN64
> #endif
>
If you only need _WIN64 defined during the Cygwin build then put this
in a Cygwin local definition else put it in the mingw64 headers.
> 4. Let the Cygwin 64 bit gcc define _WIN64 by default.
>
> I think all of these variations have up- and downsides. I just can't
> decide which is the best way to handle the problem. So, let me tell
> you what I think and then chime in, please:
>
> 1. Most straightforward, but uglifies the headers extremly. All
> later added ifdefs have to be checked so that they don't exclude
> __CYGWIN64__.
>
> 2. Better than 1 as far as readability and ugliness are concerned.
> But also requires constant vigilance so that _WIN64 doesn't creep in
> again.
>
> 3. If _WIN64 is defined in a Mingw64 header, then all projects which
> don't include windows headers are off the hook. configure is off
> the hook as well. Only projects which use `#ifdef _WIN64' within
> the code may be in trouble.
>
> 4. What can I say? This is exaclty the situation we'd like to avoid.
>
> Concerning point 3 and 4, the question on the Mingw64 IRC channel was
> this: Is that really a serious problem? Projects testing for windows
> targets usually test for _WIN32, not for _WIN64, since _WIN32 is always
> defined, on 32 and on 64 bit Windows.
>
I would argue that point, I could see some project use _WIN64 for
specific abilities of the API. Yes both are defined by default.
> Consequentially, projects for which testing for _WIN64 is an important
> design choice are windows-centric anyway and probably no serious target
> for a Cygwin port.
>
Maybe not always though. As _WIN64 specifics begin to creep into
those now supporting _WIN32.
> Given that, I am inclined to simplify the problem by choosing point 3;
> just define _WIN64 if a Windows header is included and then keep it
> at that.
>
I like this. If it is always needed then do it in the mingw64 headers
otherwise do it locally.
--
Earnie
-- https://sites.google.com/site/earnieboyd