Re: [GENERAL] MinGW compiled client library

2013-08-16 Thread Michael Cronenworth

On 08/16/2013 02:12 AM, Albe Laurenz wrote:

Yes, any patches should be posted to -hackers, in this case
with a archive reference to the discussion on -general.

Please readhttp://wiki.postgresql.org/wiki/Submitting_a_Patch

To make sure that the patch does not get lost, add it to
the next commitfest onhttps://commitfest.postgresql.org/
(this is not required for bugfixes, but helps).


Thanks for the help. Just submitted the patch.



--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general


Re: [GENERAL] MinGW compiled client library

2013-08-15 Thread Michael Cronenworth
On 08/15/2013 10:59 AM, Michael Cronenworth wrote:
> The attached patches resolve the issue.

Should I forward the patches on to the pgsql-hackers list for review or is this
list sufficient? (First time PostgreSQL hacker.)


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general


Re: [GENERAL] MinGW compiled client library

2013-08-15 Thread Michael Cronenworth
On 08/13/2013 12:35 PM, Michael Cronenworth wrote:
> When the client library (version 9.2.x) is compiled with a MinGW-w64 
> environment
> the resulting libpq.dll will not function. This has been reported previously
> with two bug reports, which have gone untouched.
> 
> Bug 8151:
> http://www.postgresql.org/message-id/e1ubelm-0007nk...@wrigleys.postgresql.org
> Bug 8162:
> http://www.postgresql.org/message-id/e1uclpd-l4...@wrigleys.postgresql.org
> 
> I have tried compiling with every option enabled and every option disabled. 
> Does
> anyone have any pointers or would anyone be willing to help solve this issue?

The connection problem was caused by incorrect error code checking after
connect(). The libpq interface defines a macro "SOCK_ERRNO" that on windows
calls WSAGetLastError(), which returns a Windows error code. The check after
connect() compares the Windows error code against the UNIX errno
EINPROGRRESS/EWOULDBLOCK.

I see there is a test in win32.h to see if EINPROGRESS is defined. It may not
have been defined in very old MinGW environments, but it is defined now. The
attached patches resolve the issue.

The compiled libpq.dll allows me to connect and run a SELECT and print out data.
--- postgresql-9.2.4/src/interfaces/libpq/fe-connect.c.orig	2013-08-15 09:08:59.850609595 -0500
+++ postgresql-9.2.4/src/interfaces/libpq/fe-connect.c	2013-08-15 09:42:59.001463906 -0500
@@ -1778,10 +1778,16 @@
 	if (connect(conn->sock, addr_cur->ai_addr,
 addr_cur->ai_addrlen) < 0)
 	{
+#ifndef WIN32
 		if (SOCK_ERRNO == EINPROGRESS ||
 			SOCK_ERRNO == EWOULDBLOCK ||
 			SOCK_ERRNO == EINTR ||
+#else
+		if (SOCK_ERRNO == WSAEINPROGRESS ||
+			SOCK_ERRNO == WSAEWOULDBLOCK ||
+			SOCK_ERRNO == WSAEINTR ||
 			SOCK_ERRNO == 0)
+#endif
 		{
 			/*
 			 * This is fine - we're in non-blocking mode, and
--- postgresql-9.2.4/src/interfaces/libpq/fe-misc.c.orig	2013-04-01 13:20:36.0 -0500
+++ postgresql-9.2.4/src/interfaces/libpq/fe-misc.c	2013-08-15 10:08:03.190928760 -0500
@@ -656,7 +656,11 @@
 		  conn->inBufSize - conn->inEnd);
 	if (nread < 0)
 	{
+#ifndef WIN32
 		if (SOCK_ERRNO == EINTR)
+#else
+		if (SOCK_ERRNO == WSAEINTR)
+#endif
 			goto retry3;
 		/* Some systems return EAGAIN/EWOULDBLOCK for no data */
 #ifdef EAGAIN
@@ -664,12 +668,20 @@
 			return someread;
 #endif
 #if defined(EWOULDBLOCK) && (!defined(EAGAIN) || (EWOULDBLOCK != EAGAIN))
+#ifndef WIN32
 		if (SOCK_ERRNO == EWOULDBLOCK)
+#else
+		if (SOCK_ERRNO == WSAEWOULDBLOCK)
+#endif
 			return someread;
 #endif
 		/* We might get ECONNRESET here if using TCP and backend died */
 #ifdef ECONNRESET
+#ifndef WIN32
 		if (SOCK_ERRNO == ECONNRESET)
+#else
+		if (SOCK_ERRNO == WSAECONNRESET)
+#endif
 			goto definitelyFailed;
 #endif
 		/* pqsecure_read set the error message for us */
@@ -749,7 +761,11 @@
 		  conn->inBufSize - conn->inEnd);
 	if (nread < 0)
 	{
+#ifndef WIN32
 		if (SOCK_ERRNO == EINTR)
+#else
+		if (SOCK_ERRNO == WSAEINTR)
+#endif
 			goto retry4;
 		/* Some systems return EAGAIN/EWOULDBLOCK for no data */
 #ifdef EAGAIN
@@ -757,12 +773,20 @@
 			return 0;
 #endif
 #if defined(EWOULDBLOCK) && (!defined(EAGAIN) || (EWOULDBLOCK != EAGAIN))
+#ifndef WIN32
 		if (SOCK_ERRNO == EWOULDBLOCK)
+#else
+		if (SOCK_ERRNO == WSAEWOULDBLOCK)
+#endif
 			return 0;
 #endif
 		/* We might get ECONNRESET here if using TCP and backend died */
 #ifdef ECONNRESET
+#ifndef WIN32
 		if (SOCK_ERRNO == ECONNRESET)
+#else
+		if (SOCK_ERRNO == WSAECONNRESET)
+#endif
 			goto definitelyFailed;
 #endif
 		/* pqsecure_read set the error message for us */
@@ -838,10 +862,18 @@
 	break;
 #endif
 #if defined(EWOULDBLOCK) && (!defined(EAGAIN) || (EWOULDBLOCK != EAGAIN))
+#ifndef WIN32
 case EWOULDBLOCK:
+#else
+case WSAEWOULDBLOCK:
+#endif
 	break;
 #endif
+#ifndef WIN32
 case EINTR:
+#else
+case WSAEINTR:
+#endif
 	continue;
 
 default:
--- postgresql-9.2.4/src/interfaces/libpq/fe-secure.c.orig	2013-08-15 10:10:44.039355056 -0500
+++ postgresql-9.2.4/src/interfaces/libpq/fe-secure.c	2013-08-15 10:22:57.767650717 -0500
@@ -433,12 +433,20 @@
 #if defined(EWOULDBLOCK) && (!defined(EAGAIN) || (EWOULDBLOCK != EAGAIN))
 case EWOULDBLOCK:
 #endif
+#ifndef WIN32
 case EINTR:
+#else
+case WSAEWOULDBLOCK:
+case WSAEINTR:
+#endif
 	/* no error message, caller is expected to retry */
 	break;
 
 #ifdef ECONNRESET
 case ECONNRESET:
+#ifdef WIN32
+case WSAECONNRESET:
+#endif
 	printfPQExpBuffer(&conn->errorMessage,
 	  libpq_gettext(
 "server closed the connection unexpectedly\n"
@@ -617,7 +625,12 @@
 #if defined(EWOULDBLOCK) && (!defined(EAGAIN) || (EWOULDBLOCK != EAGAIN))
 case EWOULDBLOCK:
 #endif
+#ifndef WIN32
 case EINTR:
+#else
+case WSAEWOULDBLOCK:
+case WSAEINTR:

Re: [GENERAL] MinGW compiled client library

2013-08-13 Thread Michael Cronenworth
On 08/13/2013 01:40 PM, John R Pierce wrote:
> They use Microsoft Visual C (I forget the exact version, but I believe most
> recent versions are supported, including the "Express" versions).

Then MinGW should be capable of producing the same binaries.

I've tried early gcc 4.7 and the latest gcc 4.8, but neither produce anything
that works.



-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general


[GENERAL] MinGW compiled client library

2013-08-13 Thread Michael Cronenworth
Hello,

When the client library (version 9.2.x) is compiled with a MinGW-w64 environment
the resulting libpq.dll will not function. This has been reported previously
with two bug reports, which have gone untouched.

Bug 8151:
http://www.postgresql.org/message-id/e1ubelm-0007nk...@wrigleys.postgresql.org
Bug 8162:
http://www.postgresql.org/message-id/e1uclpd-l4...@wrigleys.postgresql.org

I have tried compiling with every option enabled and every option disabled. Does
anyone have any pointers or would anyone be willing to help solve this issue?

What environment does EnterpriseDB use to create their Windows binaries?

Thanks,
Michael


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general