Re: mingw 64 build

On Sun, Jan 30, 2011 at 18:35, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>
>
> On 01/30/2011 11:52 AM, Magnus Hagander wrote:
>>
>> On Sun, Jan 30, 2011 at 16:47, Andrew Dunstan<andrew(at)dunslane(dot)net>  wrote:
>>>
>>> The attached patch allows building a 64 bit Windows Postgres using the
>>> mingw64 compiler from
>>>
>>> <http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Automated%20Builds/>.
>>> It works both as a native compiler and for cross-compiling (which I
>>> tested
>>> on 32 bit Windows, but could in theory be done on any of the supported
>>> hosts, including Linux, Darwin and Cygwin).
>>>
>>> The required changes are very modest, and I'd like to commit this so we
>>> can
>>> get some buildfarm coverage (I don't have an available 64 bit Windows
>>> machine for running a buildfarm member right now. but maybe someone else
>>> does.)
>>>
>>> There will be some small consequent documentation changes.
>>
>> +#ifndef _WIN32_WINNT
>>  #define _WIN32_WINNT 0x0501
>> +#endif
>>
>> That seems unsafe in general. What if _WIN32_WINNT is already defined,
>> but to something lower than 0x0501?Might be better to do:
>> #ifdef _WIN32_WINNT
>> #undef _WIN32_WINNT
>> #endif
>
>
> Right now we define it to 0x0501 unconditionally, which causes warnings on
> practically every file, because the mingw64 headers define it themselves to
> 0x0502. We don't really want to redefine it down ourselves, do we?
>
>
> Maybe we should do the undefine only if it's lower than 0x0501.

Yeah, that seems like the correct thing to do.

>> +#ifndef WIN64
>>  #define _WINSOCKAPI_
>>
>> Did you verify that that's not needed on win64-msvc? (my VM isn't
>> booted right now, so I didn't actually test it)
>
>
> No, I don't have such a setup, so testing that would be a significant burden
> to me. But the buildfarm does (hamerkop). Part of the reason for wanting to
> get this onto the buildfarm is to make sure it doesn't upset anything else.
> After all that's a major reason for the buildfarm's existence in the first
> place.

Well, I'd rather assume that it's there for a reason on the msvc
builds before, so I'd rather have the patch not change the msvc
behavior in the first place. Shouldn't be too hard to do?

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/