Removing dependency to wsock32.lib when compiling code on WIndows

On Mon, Apr 21, 2014 at 12:54 PM, Michael Paquier <michael.paquier@gmail.com

wrote:

When doing some work on Windows, I noticed that the mkvc specs in
src/tools/msvc use wsock32.lib, which is as far as I understand an
old, obsolete version of the Windows socket library. Wouldn't it make
sense to update the specs to build only with ws2_32.lib like in the
patch attached?

I created an entry in the upcoming commit fest for this patch:
https://commitfest.postgresql.org/action/patch_view?id=1440
Thanks,
--
Michael

From: "Michael Paquier" <michael.paquier@gmail.com>

When doing some work on Windows, I noticed that the mkvc specs in
src/tools/msvc use wsock32.lib, which is as far as I understand an
old, obsolete version of the Windows socket library. Wouldn't it make
sense to update the specs to build only with ws2_32.lib like in the
patch attached?

Yes, that makes sense, because wsock32.dll is an obsolete WinSock 1.1
library, while ws2_32.dll is a successor WinSock 2.0 library which is fully
compatible with the old one.

Doing "grep -lir wsock32 ." shows the following files. Could you modify and
test these files as well for code cleanup?

./configure
./configure.in
./contrib/pgcrypto/Makefile
./src/interfaces/libpq/Makefile
./src/interfaces/libpq/win32.c
./src/interfaces/libpq/win32.mak
./src/test/thread/README
./src/tools/msvc/Mkvcbuild.pm

Regards
MauMau

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

On Wed, Jun 18, 2014 at 8:37 PM, MauMau <maumau307@gmail.com> wrote:

Doing "grep -lir wsock32 ." shows the following files. Could you modify and
test these files as well for code cleanup?
./configure
./configure.in
./contrib/pgcrypto/Makefile
./src/interfaces/libpq/Makefile
./src/interfaces/libpq/win32.c
./src/interfaces/libpq/win32.mak
./src/test/thread/README
./src/tools/msvc/Mkvcbuild.pm

You are right, I only though about the MS scripts when working on this
patch. Updated patch for a complete cleanup is attached (note I
updated manually ./configure for test purposes and did not re-run
autoconf).
Regards,
--
Michael

From: "Michael Paquier" <michael.paquier@gmail.com>

You are right, I only though about the MS scripts when working on this
patch. Updated patch for a complete cleanup is attached (note I
updated manually ./configure for test purposes and did not re-run
autoconf).

I marked this patch as ready for committer. I confirmed:

* The patch content is correct.

* The patch applies cleanly. Running "grep -lir wsock32 ." after applying
the patch shows that wsock32.lib is no longer used.

* The binaries can be built with MSVC 2008 Express. I didn't try to build
on MinGW.

* The regression tests pass ("vcregress check").

However, I wonder if some DLL entries in dlls[] in
src/interfaces/libpq/win32.c should be removed. winsock.dll should
definitely be removed, because it is for 16-bit applications. I don't know
about the rest. Especially, wsock32n.dll and mswsock.dll may also be
obsolete libraries from their names. Could you look into this and revise
the patch if possible? But I don't mind if you do so.

Regards
MauMau

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

On Thu, Jun 19, 2014 at 11:13 PM, MauMau <maumau307@gmail.com> wrote:

* The patch applies cleanly. Running "grep -lir wsock32 ." after applying
the patch shows that wsock32.lib is no longer used.
However, I wonder if some DLL entries in dlls[] in
src/interfaces/libpq/win32.c should be removed. winsock.dll should
definitely be removed, because it is for 16-bit applications. I don't know
about the rest. Especially, wsock32n.dll and mswsock.dll may also be
obsolete libraries from their names. Could you look into this and revise
the patch if possible? But I don't mind if you do so.

(google-sensei..) msock32n stands for Hummingbird Socks V4 Winsock
while mswsock implements the Windows socket SPI interface. I think we
should keep them and not risking opening a can of worms, but perhaps a
Windows guru has a different opinion on the matter.
--
Michael

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

On Thu, Jun 19, 2014 at 4:13 PM, MauMau <maumau307@gmail.com> wrote:

From: "Michael Paquier" <michael.paquier@gmail.com>

You are right, I only though about the MS scripts when working on this
patch. Updated patch for a complete cleanup is attached (note I
updated manually ./configure for test purposes and did not re-run
autoconf).

I marked this patch as ready for committer. I confirmed:

I'm pretty sure this is not ready for commiter due to:

* The binaries can be built with MSVC 2008 Express. I didn't try to build
on MinGW.

Somebody needs to test it on mingw first :)

That should be an easy test for someone who has a mingw install
around, so better leave it at "needs review" so more people see it and
can run those tests.

* The regression tests pass ("vcregress check").

However, I wonder if some DLL entries in dlls[] in
src/interfaces/libpq/win32.c should be removed. winsock.dll should
definitely be removed, because it is for 16-bit applications. I don't know
about the rest. Especially, wsock32n.dll and mswsock.dll may also be
obsolete libraries from their names. Could you look into this and revise
the patch if possible? But I don't mind if you do so.

I'm with michael about the "scaryness" of touching this. Also, it is
definitely a separate patch if we do...

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

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

On Tue, Jul 15, 2014 at 8:46 PM, Magnus Hagander <magnus@hagander.net> wrote:

On Thu, Jun 19, 2014 at 4:13 PM, MauMau <maumau307@gmail.com> wrote:

From: "Michael Paquier" <michael.paquier@gmail.com>

You are right, I only though about the MS scripts when working on this
patch. Updated patch for a complete cleanup is attached (note I
updated manually ./configure for test purposes and did not re-run
autoconf).

I marked this patch as ready for committer. I confirmed:

I'm pretty sure this is not ready for commiter due to:

* The binaries can be built with MSVC 2008 Express. I didn't try to build
on MinGW.

Somebody needs to test it on mingw first :)

That should be an easy test for someone who has a mingw install
around, so better leave it at "needs review" so more people see it and
can run those tests.

I vaguely recall that I tested as well with MinGW when writing v2 of
this patch after MauMau reviewed v1. Btw, just in case, I have just
made working my MinGW box a bit more and re-tested it now. And it
worked :)

Of course someone else than the patch author with a MinGW environment
at hand is invited to test.
--
Michael

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

On Tue, Jul 15, 2014 at 2:14 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:

On Tue, Jul 15, 2014 at 8:46 PM, Magnus Hagander <magnus@hagander.net> wrote:

On Thu, Jun 19, 2014 at 4:13 PM, MauMau <maumau307@gmail.com> wrote:

From: "Michael Paquier" <michael.paquier@gmail.com>

You are right, I only though about the MS scripts when working on this
patch. Updated patch for a complete cleanup is attached (note I
updated manually ./configure for test purposes and did not re-run
autoconf).

I marked this patch as ready for committer. I confirmed:

I'm pretty sure this is not ready for commiter due to:

* The binaries can be built with MSVC 2008 Express. I didn't try to build
on MinGW.

Somebody needs to test it on mingw first :)

That should be an easy test for someone who has a mingw install
around, so better leave it at "needs review" so more people see it and
can run those tests.

I vaguely recall that I tested as well with MinGW when writing v2 of
this patch after MauMau reviewed v1. Btw, just in case, I have just
made working my MinGW box a bit more and re-tested it now. And it
worked :)

Of course someone else than the patch author with a MinGW environment
at hand is invited to test.

Thanks!

I think that's enough - the functionality has already been verified
elsewhere, and the contents look good :) We'll use the buidlfarm to
see if there are any weird version-dependencies...

Thus - applied!

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

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

On Tue, Jul 15, 2014 at 9:20 PM, Magnus Hagander <magnus@hagander.net> wrote:

On Tue, Jul 15, 2014 at 2:14 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:

Of course someone else than the patch author with a MinGW environment
at hand is invited to test.

Thanks!

I think that's enough - the functionality has already been verified
elsewhere, and the contents look good :) We'll use the buidlfarm to
see if there are any weird version-dependencies...

Thus - applied!

OK. Thanks a lot!
--
Michael

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

On Tue, Jul 15, 2014 at 5:14 AM, Michael Paquier <michael.paquier@gmail.com>
wrote:

On Tue, Jul 15, 2014 at 8:46 PM, Magnus Hagander <magnus@hagander.net>
wrote:

On Thu, Jun 19, 2014 at 4:13 PM, MauMau <maumau307@gmail.com> wrote:

From: "Michael Paquier" <michael.paquier@gmail.com>

You are right, I only though about the MS scripts when working on this
patch. Updated patch for a complete cleanup is attached (note I
updated manually ./configure for test purposes and did not re-run
autoconf).

I marked this patch as ready for committer. I confirmed:

I'm pretty sure this is not ready for commiter due to:

* The binaries can be built with MSVC 2008 Express. I didn't try to

build

on MinGW.

Somebody needs to test it on mingw first :)

That should be an easy test for someone who has a mingw install
around, so better leave it at "needs review" so more people see it and
can run those tests.

I vaguely recall that I tested as well with MinGW when writing v2 of
this patch after MauMau reviewed v1. Btw, just in case, I have just
made working my MinGW box a bit more and re-tested it now. And it
worked :)

Of course someone else than the patch author with a MinGW environment
at hand is invited to test.

I guess I should have done that....

While trying to test more recent stuff against mingw, I kept running into a
problem which bisected down to this (a16bac36eca8158cbf78987e953).

I am following the instructions at
https://wiki.postgresql.org/wiki/Building_With_MinGW,
using the mingw64 set of instructions and of course the git instructions.
Except that I am running as my own user, not creating a dummy account, and
I am using local hardware, not an amazon rental.

This is the warning/error I get:

auth.c: In function 'ClientAuthentication':
auth.c:458:6: warning: implicit declaration of function 'gai_strerror'
[-Wimplicit-function-declaration]
auth.c:458:6: warning: format '%s' expects argument of type 'char *', but
argument 3 has type 'int' [-Wformat]
auth.c:458:6: warning: format '%s' expects argument of type 'char *', but
argument 2 has type 'int' [-Wformat]
auth.c:476:6: warning: format '%s' expects argument of type 'char *', but
argument 3 has type 'int' [-Wformat]
auth.c:476:6: warning: format '%s' expects argument of type 'char *', but
argument 2 has type 'int' [-Wformat]
auth.c: In function 'CheckRADIUSAuth':
auth.c:2282:3: warning: format '%s' expects argument of type 'char *', but
argument 3 has type 'int' [-Wformat]
hba.c: In function 'parse_hba_line':
hba.c:1060:5: warning: implicit declaration of function 'gai_strerror'
[-Wimplicit-function-declaration]
hba.c:1060:5: warning: format '%s' expects argument of type 'char *', but
argument 3 has type 'int' [-Wformat]
hba.c:1131:6: warning: format '%s' expects argument of type 'char *', but
argument 3 has type 'int' [-Wformat]
hba.c: In function 'parse_hba_auth_opt':
hba.c:1607:4: warning: format '%s' expects argument of type 'char *', but
argument 3 has type 'int' [-Wformat]
pqcomm.c: In function 'StreamServerPort':
pqcomm.c:334:4: warning: implicit declaration of function 'gai_strerror'
[-Wimplicit-function-declaration]
pqcomm.c:334:4: warning: format '%s' expects argument of type 'char *', but
argument 4 has type 'int' [-Wformat]
pqcomm.c:338:4: warning: format '%s' expects argument of type 'char *', but
argument 3 has type 'int' [-Wformat]
mingwcompat.c:60:1: warning: 'RegisterWaitForSingleObject' redeclared
without dllimport attribute: previous dllimport ignored [-Wattributes]
pgstat.c: In function 'pgstat_init':
pgstat.c:353:3: warning: implicit declaration of function 'gai_strerror'
[-Wimplicit-function-declaration]
pgstat.c:353:3: warning: format '%s' expects argument of type 'char *', but
argument 2 has type 'int' [-Wformat]
postmaster.c: In function 'BackendInitialize':
postmaster.c:3938:3: warning: implicit declaration of function
'gai_strerror' [-Wimplicit-function-declaration]
postmaster.c:3938:3: warning: format '%s' expects argument of type 'char
*', but argument 2 has type 'int' [-Wformat]
libpq/auth.o:auth.c:(.text+0x1949): undefined reference to `gai_strerror'
libpq/auth.o:auth.c:(.text+0x19c4): undefined reference to `gai_strerror'
libpq/auth.o:auth.c:(.text+0x1b1a): undefined reference to `gai_strerror'
libpq/auth.o:auth.c:(.text+0x1cb4): undefined reference to `gai_strerror'
libpq/auth.o:auth.c:(.text+0x1cdc): undefined reference to `gai_strerror'
libpq/hba.o:hba.c:(.text+0x1fa0): more undefined references to
`gai_strerror' follow
collect2.exe: error: ld returned 1 exit status
make[2]: *** [postgres] Error 1
make[1]: *** [all-backend-recurse] Error 2
make: *** [all-src-recurse] Error 2

Any suggestions on what to try? This patch doesn't seem to explicitly
mention gai_strerror at all, so it must be some indirect effect.

Cheers,

Jeff

On Mon, Aug 11, 2014 at 11:02:48AM -0700, Jeff Janes wrote:

While trying to test more recent stuff against mingw, I kept running into a
problem which bisected down to this (a16bac36eca8158cbf78987e953).

This is the warning/error I get:

auth.c: In function 'ClientAuthentication':
auth.c:458:6: warning: implicit declaration of function 'gai_strerror'
[-Wimplicit-function-declaration]

libpq/auth.o:auth.c:(.text+0x1949): undefined reference to `gai_strerror'
libpq/auth.o:auth.c:(.text+0x19c4): undefined reference to `gai_strerror'
libpq/auth.o:auth.c:(.text+0x1b1a): undefined reference to `gai_strerror'
libpq/auth.o:auth.c:(.text+0x1cb4): undefined reference to `gai_strerror'
libpq/auth.o:auth.c:(.text+0x1cdc): undefined reference to `gai_strerror'

Any suggestions on what to try? This patch doesn't seem to explicitly
mention gai_strerror at all, so it must be some indirect effect.

I, too, encountered that. The patch let "configure" detect HAVE_GETADDRINFO
under MinGW-w64; passing "ac_cv_func_getaddrinfo=no" on the configure command
line is a workaround. Under !HAVE_GETADDRINFO, "configure" arranges to build
src/port/getaddrinfo.c, and src/include/getaddrinfo.h injects the replacement
gai_strerror() prototype. That understandably doesn't happen in a
HAVE_GETADDRINFO build, yet src/include/port/win32/sys/socket.h does the
following unconditionally:

/*
* we can't use the windows gai_strerror{AW} functions because
* they are defined inline in the MS header files. So we'll use our
* own
*/
#undef gai_strerror

Somehow or other, we must bring these parts into agreement.

--
Noah Misch
EnterpriseDB http://www.enterprisedb.com

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

On Tue, Aug 12, 2014 at 9:43 AM, Noah Misch <noah@leadboat.com> wrote:

Somehow or other, we must bring these parts into agreement.

It is interesting to see that with MinGW-32b getaddrinfo is still set
to no at configure phase. What if we simply wrap "undef gai_strerror"
like in the patch attached? I just set up an environment with MinGW-64
and I was able to build the code (tested as well with MinGW-32 btw).

Another idea would be to enforce getaddrinfo to no at configure for
MinGW environments.
Thoughts?
--
Michael

On Tue, Aug 12, 2014 at 01:58:17PM +0900, Michael Paquier wrote:

On Tue, Aug 12, 2014 at 9:43 AM, Noah Misch <noah@leadboat.com> wrote:

Somehow or other, we must bring these parts into agreement.

It is interesting to see that with MinGW-32b getaddrinfo is still set
to no at configure phase. What if we simply wrap "undef gai_strerror"
like in the patch attached? I just set up an environment with MinGW-64
and I was able to build the code (tested as well with MinGW-32 btw).

It's easy to devise something that fixes the build. What is the right fix,
and why?

Note that MinGW-w64 is available in both 32-bit and 64-bit. It is a fork of
MinGW, which is always 32-bit. I experienced the problem with 64-bit
MinGW-w64; I don't know how 32-bit MinGW-w64 compares.

Another idea would be to enforce getaddrinfo to no at configure for
MinGW environments.

Consistency with the MSVC build is desirable, either HAVE_GETADDRINFO for both
or !HAVE_GETADDRINFO for both.

nm

--
Noah Misch
EnterpriseDB http://www.enterprisedb.com

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

On Mon, Aug 11, 2014 at 10:48 PM, Noah Misch <noah@leadboat.com> wrote:

Consistency with the MSVC build is desirable, either HAVE_GETADDRINFO for both
or !HAVE_GETADDRINFO for both.

Hm. Looking here getattrinfo has been added in ws2_32 and was not
present in wsock32:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms738520%28v=vs.85%29.aspx

And this change in configure.in is the root cause of the regression:
-AC_SEARCH_LIBS(socket, [socket wsock32])
+AC_SEARCH_LIBS(socket, [socket ws2_32])

Btw, how do you determine if MSVC is using HAVE_GETADDRINFO? Is it
decided by the inclusion of getaddrinfo.c in @pgportfiles of
Mkvdbuild.pm?
--
Michael

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

On Fri, Aug 15, 2014 at 12:49:36AM -0700, Michael Paquier wrote:

Btw, how do you determine if MSVC is using HAVE_GETADDRINFO? Is it
decided by the inclusion of getaddrinfo.c in @pgportfiles of
Mkvdbuild.pm?

src/include/pg_config.h.win32 dictates it, and we must keep @pgportfiles
synchronized with the former's verdict.

--
Noah Misch
EnterpriseDB http://www.enterprisedb.com

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

On 08/15/2014 11:00 PM, Noah Misch wrote:

On Fri, Aug 15, 2014 at 12:49:36AM -0700, Michael Paquier wrote:

Btw, how do you determine if MSVC is using HAVE_GETADDRINFO? Is it
decided by the inclusion of getaddrinfo.c in @pgportfiles of
Mkvdbuild.pm?

src/include/pg_config.h.win32 dictates it, and we must keep @pgportfiles
synchronized with the former's verdict.

What's happening about this? Buildfarm animal jacana is consistently red
because of this.

cheers

andrew

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

On Thu, Aug 21, 2014 at 09:18:22AM -0400, Andrew Dunstan wrote:

On 08/15/2014 11:00 PM, Noah Misch wrote:

On Fri, Aug 15, 2014 at 12:49:36AM -0700, Michael Paquier wrote:

Btw, how do you determine if MSVC is using HAVE_GETADDRINFO? Is it
decided by the inclusion of getaddrinfo.c in @pgportfiles of
Mkvdbuild.pm?

src/include/pg_config.h.win32 dictates it, and we must keep @pgportfiles
synchronized with the former's verdict.

What's happening about this? Buildfarm animal jacana is consistently
red because of this.

If nobody plans to do the aforementioned analysis in the next 4-7 days, I
suggest we adopt one of Michael's suggestions: force "configure" to reach its
old conclusion about getaddrinfo() on Windows. Then the analysis can proceed
on an unhurried schedule.

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

On Fri, Aug 15, 2014 at 8:00 PM, Noah Misch <noah@leadboat.com> wrote:

On Fri, Aug 15, 2014 at 12:49:36AM -0700, Michael Paquier wrote:

Btw, how do you determine if MSVC is using HAVE_GETADDRINFO? Is it
decided by the inclusion of getaddrinfo.c in @pgportfiles of
Mkvdbuild.pm?

src/include/pg_config.h.win32 dictates it, and we must keep @pgportfiles
synchronized with the former's verdict.

Thanks.

Looking more into that, I am seeing that MinGW-32 is failing to find socket
at configure, contrary to MinGW-64.

Here is what happens for MinGW-64 at configure:
configure:7638: checking for library containing socket
[...]
configure:7669: x86_64-w64-mingw32-gcc -o conftest.exe -Wall
-Wmissing-prototypes -Wpointer-arith \
-Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute
-Wformat-security -fno-stri\
ct-aliasing -fwrapv -fexcess-precision=standard -g
-I./src/include/port/win32 -DEXEC_BACKEND -Wl\
,--allow-multiple-definition -Wl,--disable-auto-import conftest.c -lws2_32
-lm >&5
configure:7669: $? = 0
configure:7686: result: -lws2_32

And for MinGW-32:
configure:7638: checking for library containing socket
[...]
configure:7669: gcc -o conftest.exe -Wall -Wmissing-prototypes
-Wpointer-arith -Wdeclaration-after\
-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security
-fno-strict-aliasing -fwrapv\
-fexcess-precision=standard -g -I./src/include/port/win32
-DEXEC_BACKEND -Wl,--allow-multiple-d\
efinition -Wl,--disable-auto-import conftest.c -lws2_32 -lm >&5
C:\Users\ioltas\AppData\Local\Temp\cciNV1Y8.o: In function `main':
c:\Users\ioltas\git\postgres/conftest.c:33: undefined reference to `socket'
collect2.exe: error: ld returned 1 exit status
configure:7669: $? = 1
[...]
configure:7686: result: no

Now, what happens is that if configure finds socket within ws2_32 it adds
it to LIBS, making this variable look like that:
- MinGW-32: LIBS="-lm "
- MinGW-64: LIBS="-lm -lws2_32"
And as LIBS is used afterwards to check the presence of several functions,
including getaddrinfo, those different values of LIBS make HAVE_GETADDRINFO
set to different values in MinGW-32 and 64, respectively undefined and
defined.

I am not sure which way is better, do we want HAVE_GETADDRINFO or
!HAVE_GETADDRINFO in all Windows builds? If we choose the former, we'll
need to understand why -lws2_32 is not added to LIBS for MinGW-32. If we
choose the latter, we would need to remove -lws2_32 from LIBS with MinGW-64
for consistency with MinGW-32 I think.

Either way, currently MSVC uses !HAVE_GETADDRINFO. So in bonus to this
anamysis, the patch attached makes possible the use of HAVE_GETADDRINFO.
This could be needed for the final solution we seek.

Note that the undef gai_strerror in src/include/port/win32/sys/socket.h has
been added in 2005 by this commit:
commit: a310a1d80c6535774115838010f9c337d08d45cc
author: Tom Lane <tgl@sss.pgh.pa.us>
date: Fri, 26 Aug 2005 03:15:12 +0000
Some more mop-up for Windows IPv6 support. Andrew Dunstan

I don't know the opinions of the others, but removing a tweak like this one
may not be a bad thing to simplify code.

Regards,
--
Michael

On Fri, Aug 22, 2014 at 04:58:47PM +0900, Michael Paquier wrote:

Looking more into that, I am seeing that MinGW-32 is failing to find socket
at configure, contrary to MinGW-64.

Here is what happens for MinGW-64 at configure:
configure:7638: checking for library containing socket
[...]
configure:7669: x86_64-w64-mingw32-gcc -o conftest.exe -Wall
-Wmissing-prototypes -Wpointer-arith \
-Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute
-Wformat-security -fno-stri\
ct-aliasing -fwrapv -fexcess-precision=standard -g
-I./src/include/port/win32 -DEXEC_BACKEND -Wl\
,--allow-multiple-definition -Wl,--disable-auto-import conftest.c -lws2_32
-lm >&5
configure:7669: $? = 0
configure:7686: result: -lws2_32

And for MinGW-32:
configure:7638: checking for library containing socket
[...]
configure:7669: gcc -o conftest.exe -Wall -Wmissing-prototypes
-Wpointer-arith -Wdeclaration-after\
-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security
-fno-strict-aliasing -fwrapv\
-fexcess-precision=standard -g -I./src/include/port/win32
-DEXEC_BACKEND -Wl,--allow-multiple-d\
efinition -Wl,--disable-auto-import conftest.c -lws2_32 -lm >&5
C:\Users\ioltas\AppData\Local\Temp\cciNV1Y8.o: In function `main':
c:\Users\ioltas\git\postgres/conftest.c:33: undefined reference to `socket'
collect2.exe: error: ld returned 1 exit status

I see that ws2_32.def for 64-bit MinGW-w64 exports plain "socket", while
32-bit MinGW-w64 and 32-bit MinGW export "socket@12". In other words, 64-bit
MinGW-w64 exports a "__cdecl socket" function, and the others export a
"__stdcall socket" function. AC_SEARCH_LIBS doesn't work with __stdcall.

I am not sure which way is better, do we want HAVE_GETADDRINFO or
!HAVE_GETADDRINFO in all Windows builds? If we choose the former, we'll
need to understand why -lws2_32 is not added to LIBS for MinGW-32. If we
choose the latter, we would need to remove -lws2_32 from LIBS with MinGW-64
for consistency with MinGW-32 I think.

HAVE_GETADDRINFO is preferable whenever the OS functions getaddrinfo.h would
replace are fully adequate. When PostgreSQL established its longstanding
Windows behavior in this area, that was not so. A few generations of Windows
have since gone out of support, so perhaps the situation has changed.

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