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.