Thread: MinGW compiled client library
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-5L@wrigleys.postgresql.org Bug 8162: http://www.postgresql.org/message-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? What environment does EnterpriseDB use to create their Windows binaries? Thanks, Michael
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
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.
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
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
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
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-5L@wrigleys.postgresql.org > Bug 8162: > http://www.postgresql.org/message-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.
Attachment
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.)
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
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.