MinGW compiled client library

On 8/13/2013 10:35 AM, Michael Cronenworth wrote:

What environment does EnterpriseDB use to create their Windows binaries?

They use Microsoft Visual C (I forget the exact version, but I believe
most recent versions are supported, including the "Express" versions).

--
john r pierce 37N 122W
somewhere on the middle of the left coast

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

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

On 8/13/2013 5:25 PM, Michael Cronenworth wrote:

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'm curious what led you to that conclusion. The MinGW site itself does
not make such a claim. See http://www.mingw.org/wiki/MixingCompilers.

--
Guy Rouillier

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

On 8/13/2013 2:25 PM, Michael Cronenworth wrote:

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.

no. GCC uses a totally different libc in its generated code. that alone
ensures its binaries are not directly comparable. linking code with
incompatible libc's is gonna result in some gnarly messes, imagine what
kind of ugly stuff could happen if you used one malloc and another free ?

--
john r pierce 37N 122W
somewhere on the middle of the left coast

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

On 08/14/2013 08:57 AM, John R Pierce wrote:

no. GCC uses a totally different libc in its generated code. that alone
ensures its binaries are not directly comparable. linking code with
incompatible libc's is gonna result in some gnarly messes, imagine what
kind of ugly stuff could happen if you used one malloc and another free ?

Windows code is required to defend against this and PostgreSQL is no
exception.

It's very common on Windows for different libraries to use different
libcs. Horrible, but common. They deal with this by doing things like:

* Always free()ing memory in the same module it was malloc()'d in;
* Never passing file handles around, instead using wrapper functions;

etc.

libpq compiled with gcc should work in an MSVC-compiled executable so
long as the port/ code for mingw is correct and there are no
undiscovered portability bugs.

In this case I'm wondering if we've got an issue with selection of
socket flags. Michael, can you try some older versions and see if you
can find when this problem first appeared? Does it only affect mingw-64,
or is the 32-bit version affected too?

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

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

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:
/messages/by-id/E1UbELM-0007NK-5L@wrigleys.postgresql.org
Bug 8162:
/messages/by-id/E1UcLPd-0000L4-TI@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.

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

Michael Cronenworth wrote:

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.)

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

Please read http://wiki.postgresql.org/wiki/Submitting_a_Patch

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

Yours,
Laurenz Albe

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

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