mingw 64 build
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.
cheers
andrew
Attachments:
w64.patchtext/x-patch; name=w64.patchDownload
diff --git a/config/ac_func_accept_argtypes.m4 b/config/ac_func_accept_argtypes.m4
index 7cb5cb3..1e77179 100644
--- a/config/ac_func_accept_argtypes.m4
+++ b/config/ac_func_accept_argtypes.m4
@@ -38,6 +38,7 @@ dnl
# 'int' as the result, because that ought to work best.
#
# On Win32, accept() returns 'unsigned int PASCAL'
+# Win64 uses SOCKET for return and arg1
AC_DEFUN([AC_FUNC_ACCEPT_ARGTYPES],
[AC_MSG_CHECKING([types of arguments for accept()])
@@ -45,8 +46,8 @@ AC_DEFUN([AC_FUNC_ACCEPT_ARGTYPES],
[AC_CACHE_VAL(ac_cv_func_accept_arg1,dnl
[AC_CACHE_VAL(ac_cv_func_accept_arg2,dnl
[AC_CACHE_VAL(ac_cv_func_accept_arg3,dnl
- [for ac_cv_func_accept_return in 'int' 'unsigned int PASCAL'; do
- for ac_cv_func_accept_arg1 in 'int' 'unsigned int'; do
+ [for ac_cv_func_accept_return in 'int' 'unsigned int PASCAL' 'SOCKET'; do
+ for ac_cv_func_accept_arg1 in 'int' 'unsigned int' 'SOCKET'; do
for ac_cv_func_accept_arg2 in 'struct sockaddr *' 'const struct sockaddr *' 'void *'; do
for ac_cv_func_accept_arg3 in 'int' 'size_t' 'socklen_t' 'unsigned int' 'void'; do
AC_TRY_COMPILE(
diff --git a/configure b/configure
index 8ff61a6..cc809ac 100755
--- a/configure
+++ b/configure
@@ -18696,8 +18696,8 @@ else
if test "${ac_cv_func_accept_arg3+set}" = set; then
$as_echo_n "(cached) " >&6
else
- for ac_cv_func_accept_return in 'int' 'unsigned int PASCAL'; do
- for ac_cv_func_accept_arg1 in 'int' 'unsigned int'; do
+ for ac_cv_func_accept_return in 'int' 'unsigned int PASCAL' 'SOCKET'; do
+ for ac_cv_func_accept_arg1 in 'int' 'unsigned int' 'SOCKET'; do
for ac_cv_func_accept_arg2 in 'struct sockaddr *' 'const struct sockaddr *' 'void *'; do
for ac_cv_func_accept_arg3 in 'int' 'size_t' 'socklen_t' 'unsigned int' 'void'; do
cat >conftest.$ac_ext <<_ACEOF
diff --git a/src/include/c.h b/src/include/c.h
index 634b21f..af1be94 100644
--- a/src/include/c.h
+++ b/src/include/c.h
@@ -58,7 +58,7 @@
#endif
#include "postgres_ext.h"
-#if _MSC_VER >= 1400
+#if _MSC_VER >= 1400 || defined(WIN64)
#define errcode __msvc_errcode
#include <crtdefs.h>
#undef errcode
diff --git a/src/include/port.h b/src/include/port.h
index 7ad464c..4d40cef 100644
--- a/src/include/port.h
+++ b/src/include/port.h
@@ -325,8 +325,12 @@ extern FILE *pgwin32_fopen(const char *, const char *);
#define fopen(a,b) pgwin32_fopen(a,b)
#endif
+#ifndef popen
#define popen(a,b) _popen(a,b)
+#endif
+#ifndef pclose
#define pclose(a) _pclose(a)
+#endif
/* New versions of MingW have gettimeofday, old mingw and msvc don't */
#ifndef HAVE_GETTIMEOFDAY
diff --git a/src/include/port/win32.h b/src/include/port/win32.h
index 93439f7..507a61e 100644
--- a/src/include/port/win32.h
+++ b/src/include/port/win32.h
@@ -4,7 +4,9 @@
#define WIN32_ONLY_COMPILER
#endif
+#ifndef _WIN32_WINNT
#define _WIN32_WINNT 0x0501
+#endif
/*
* Always build with SSPI support. Keep it as a #define in case
* we want a switch to disable it sometime in the future.
@@ -17,10 +19,12 @@
#undef mkdir
#undef ERROR
+#ifndef WIN64
#define _WINSOCKAPI_
-#include <windows.h>
+#endif
#include <winsock2.h>
#include <ws2tcpip.h>
+#include <windows.h>
#undef small
#include <process.h>
#include <signal.h>
diff --git a/src/include/port/win32/sys/socket.h b/src/include/port/win32/sys/socket.h
index 6947ec0..edaee6a 100644
--- a/src/include/port/win32/sys/socket.h
+++ b/src/include/port/win32/sys/socket.h
@@ -13,6 +13,7 @@
*/
#include <winsock2.h>
#include <ws2tcpip.h>
+#include <windows.h>
#undef ERROR
#undef small
diff --git a/src/port/getaddrinfo.c b/src/port/getaddrinfo.c
index 654858e..fabd50d 100644
--- a/src/port/getaddrinfo.c
+++ b/src/port/getaddrinfo.c
@@ -329,8 +329,7 @@ gai_strerror(int errcode)
return "Not enough memory";
#endif
#ifdef EAI_NODATA
-#ifndef WIN32_ONLY_COMPILER /* MSVC complains because another case has the
- * same value */
+#if !defined(WIN64) && !defined(WIN32_ONLY_COMPILER) /* MSVC/WIN64 duplicate */
case EAI_NODATA:
return "No host data of that type was found";
#endif
diff --git a/src/test/regress/resultmap b/src/test/regress/resultmap
index 7bfcee2..d02d221 100644
--- a/src/test/regress/resultmap
+++ b/src/test/regress/resultmap
@@ -1,11 +1,14 @@
float4:out:i.86-pc-mingw32=float4-exp-three-digits.out
+float4:out:x86_64-w64-mingw32=float4-exp-three-digits.out
float4:out:i.86-pc-win32vc=float4-exp-three-digits.out
float8:out:i.86-.*-freebsd=float8-small-is-zero.out
float8:out:i.86-.*-openbsd=float8-small-is-zero.out
float8:out:i.86-.*-netbsd=float8-small-is-zero.out
float8:out:m68k-.*-netbsd=float8-small-is-zero.out
float8:out:i.86-pc-mingw32=float8-exp-three-digits-win32.out
+float8:out:x86_64-w64-mingw32=float8-exp-three-digits-win32.out
float8:out:i.86-pc-win32vc=float8-exp-three-digits-win32.out
float8:out:i.86-pc-cygwin=float8-small-is-zero.out
int8:out:i.86-pc-mingw32=int8-exp-three-digits.out
+int8:out:x86_64-w64-mingw32=int8-exp-three-digits.out
int8:out:i.86-pc-win32vc=int8-exp-three-digits.out
On Sun, Jan 30, 2011 at 16:47, Andrew Dunstan <andrew@dunslane.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
instead?
+#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)
Other than those comments, looks good to me.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On 01/30/2011 11:52 AM, Magnus Hagander wrote:
On Sun, Jan 30, 2011 at 16:47, Andrew Dunstan<andrew@dunslane.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 +#endifThat 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.
+#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.
cheers
andrew
On Sun, Jan 30, 2011 at 18:35, Andrew Dunstan <andrew@dunslane.net> wrote:
On 01/30/2011 11:52 AM, Magnus Hagander wrote:
On Sun, Jan 30, 2011 at 16:47, Andrew Dunstan<andrew@dunslane.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 +#endifThat 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
#endifRight 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/