Re: [HACKERS] Removing dependency to wsock32.lib when compiling code on WIndows
On Thu, Aug 21, 2014 at 11:29:31PM -0400, Noah Misch wrote: On Thu, Aug 21, 2014 at 09:18:22AM -0400, Andrew Dunstan wrote: 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. Done. Incidentally, jacana takes an exorbitant amount of time, most recently 87 minutes, to complete the ecpg-check step. Frogmouth takes 4 minutes, and none of the other steps have such a large multiplier between the two animals. That pattern isn't new and appears on multiple branches. I wonder if ecpg tickles a performance bug in 64-bit MinGW-w64. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Removing dependency to wsock32.lib when compiling code on WIndows
On 08/29/2014 10:15 AM, Noah Misch wrote: On Thu, Aug 21, 2014 at 11:29:31PM -0400, Noah Misch wrote: On Thu, Aug 21, 2014 at 09:18:22AM -0400, Andrew Dunstan wrote: 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. Done. Incidentally, jacana takes an exorbitant amount of time, most recently 87 minutes, to complete the ecpg-check step. Frogmouth takes 4 minutes, and none of the other steps have such a large multiplier between the two animals. That pattern isn't new and appears on multiple branches. I wonder if ecpg tickles a performance bug in 64-bit MinGW-w64. Good pickup. I wonder what it could be. 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
Re: [HACKERS] Removing dependency to wsock32.lib when compiling code on WIndows
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
Re: [HACKERS] Removing dependency to wsock32.lib when compiling code on WIndows
On Fri, Aug 15, 2014 at 8:00 PM, Noah Misch n...@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 t...@sss.pgh.pa.us
date: Fri, 26 Aug 2005 03:15:12 +
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
diff --git a/src/include/pg_config.h.win32 b/src/include/pg_config.h.win32
index bce67a2..903246d 100644
--- a/src/include/pg_config.h.win32
+++ b/src/include/pg_config.h.win32
@@ -143,7 +143,7 @@
#define HAVE_FUNCNAME__FUNCTION 1
/* Define to 1 if you have getaddrinfo(). */
-/* #undef HAVE_GETADDRINFO */
+#define HAVE_GETADDRINFO 1
/* Define to 1 if you have the `gethostbyname_r' function. */
/* #undef HAVE_GETHOSTBYNAME_R */
diff --git a/src/include/port/win32/sys/socket.h b/src/include/port/win32/sys/socket.h
index edaee6a..4bd08f0 100644
--- a/src/include/port/win32/sys/socket.h
+++ b/src/include/port/win32/sys/socket.h
@@ -23,11 +23,4 @@
#define ERROR PGERROR
#endif
-/*
- * 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
-
#endif /* WIN32_SYS_SOCKET_H */
diff --git a/src/tools/msvc/Mkvcbuild.pm b/src/tools/msvc/Mkvcbuild.pm
index 004942c..177879e 100644
--- a/src/tools/msvc/Mkvcbuild.pm
+++ b/src/tools/msvc/Mkvcbuild.pm
@@ -66,7 +66,7 @@ sub mkvcbuild
our @pgportfiles = qw(
chklocale.c crypt.c fls.c fseeko.c getrusage.c inet_aton.c random.c
- srandom.c getaddrinfo.c gettimeofday.c inet_net_ntop.c kill.c open.c
+ srandom.c gettimeofday.c inet_net_ntop.c kill.c open.c
erand48.c snprintf.c strlcat.c strlcpy.c dirmod.c noblock.c path.c
pgcheckdir.c pg_crc.c pgmkdirp.c pgsleep.c pgstrcasecmp.c pqsignal.c
mkdtemp.c qsort.c qsort_arg.c quotes.c system.c
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Removing dependency to wsock32.lib when compiling code on WIndows
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
Re: [HACKERS] Removing dependency to wsock32.lib when compiling code on WIndows
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
Re: [HACKERS] Removing dependency to wsock32.lib when compiling code on WIndows
On Mon, Aug 11, 2014 at 10:48 PM, Noah Misch n...@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
Re: [HACKERS] Removing dependency to wsock32.lib when compiling code on WIndows
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
Re: [HACKERS] Removing dependency to wsock32.lib when compiling code on WIndows
On Tue, Jul 15, 2014 at 5:14 AM, Michael Paquier michael.paqu...@gmail.com wrote: On Tue, Jul 15, 2014 at 8:46 PM, Magnus Hagander mag...@hagander.net wrote: On Thu, Jun 19, 2014 at 4:13 PM, MauMau maumau...@gmail.com wrote: From: Michael Paquier michael.paqu...@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
Re: [HACKERS] Removing dependency to wsock32.lib when compiling code on WIndows
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
Re: [HACKERS] Removing dependency to wsock32.lib when compiling code on WIndows
On Tue, Aug 12, 2014 at 9:43 AM, Noah Misch n...@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 From 284aff1932d085587aa98a6023d8a6bc4ab9a16a Mon Sep 17 00:00:00 2001 From: Michael Paquier mich...@otacoo.com Date: Mon, 11 Aug 2014 19:11:45 -0700 Subject: [PATCH] Fix build error of MinGW-64 caused by incorrect gai_strerror Since commit a16bac3, configure detects HAVE_GETADDRINFO at configure phase in builds done with MinGW-64, resulting in an incorrect definition of gai_strerror as this is inconditionally undefined in src/include/port/win32/sys/socket.h. This commit simply prevents gai_strerror from being undefined when HAVE_GETADDRINFO is detected. This error has been first triggered with libpq, but with no doubts it may have been present in other places, libpq being only the first one to fail. --- src/include/port/win32/sys/socket.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/include/port/win32/sys/socket.h b/src/include/port/win32/sys/socket.h index edaee6a..33e697a 100644 --- a/src/include/port/win32/sys/socket.h +++ b/src/include/port/win32/sys/socket.h @@ -28,6 +28,8 @@ * they are defined inline in the MS header files. So we'll use our * own */ +#if !defined(HAVE_GETADDRINFO) #undef gai_strerror +#endif #endif /* WIN32_SYS_SOCKET_H */ -- 2.0.4 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Removing dependency to wsock32.lib when compiling code on WIndows
On Tue, Aug 12, 2014 at 01:58:17PM +0900, Michael Paquier wrote: On Tue, Aug 12, 2014 at 9:43 AM, Noah Misch n...@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
Re: [HACKERS] Removing dependency to wsock32.lib when compiling code on WIndows
On Thu, Jun 19, 2014 at 4:13 PM, MauMau maumau...@gmail.com wrote: From: Michael Paquier michael.paqu...@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
Re: [HACKERS] Removing dependency to wsock32.lib when compiling code on WIndows
On Tue, Jul 15, 2014 at 8:46 PM, Magnus Hagander mag...@hagander.net wrote: On Thu, Jun 19, 2014 at 4:13 PM, MauMau maumau...@gmail.com wrote: From: Michael Paquier michael.paqu...@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
Re: [HACKERS] Removing dependency to wsock32.lib when compiling code on WIndows
On Tue, Jul 15, 2014 at 2:14 PM, Michael Paquier michael.paqu...@gmail.com wrote: On Tue, Jul 15, 2014 at 8:46 PM, Magnus Hagander mag...@hagander.net wrote: On Thu, Jun 19, 2014 at 4:13 PM, MauMau maumau...@gmail.com wrote: From: Michael Paquier michael.paqu...@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
Re: [HACKERS] Removing dependency to wsock32.lib when compiling code on WIndows
On Tue, Jul 15, 2014 at 9:20 PM, Magnus Hagander mag...@hagander.net wrote: On Tue, Jul 15, 2014 at 2:14 PM, Michael Paquier michael.paqu...@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
Re: [HACKERS] Removing dependency to wsock32.lib when compiling code on WIndows
On Wed, Jun 18, 2014 at 8:37 PM, MauMau maumau...@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 f429372f402057591ede3239e69e4b70fb846751 Mon Sep 17 00:00:00 2001
From: Michael Paquier mich...@otacoo.com
Date: Thu, 19 Jun 2014 16:26:38 +0900
Subject: [PATCH] Remove usage of wsock32 in Windows builds
MS scripts, as well as Windows port Makefile are cleaned up. 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.
---
configure | 2 +-
configure.in | 2 +-
contrib/pgcrypto/Makefile | 2 +-
src/interfaces/libpq/Makefile | 2 +-
src/interfaces/libpq/win32.c | 3 ---
src/interfaces/libpq/win32.mak | 2 +-
src/test/thread/README | 2 +-
src/tools/msvc/Mkvcbuild.pm| 13 +
8 files changed, 11 insertions(+), 17 deletions(-)
diff --git a/configure b/configure
index da89c69..892f880 100755
--- a/configure
+++ b/configure
@@ -7661,7 +7661,7 @@ return socket ();
return 0;
}
_ACEOF
-for ac_lib in '' socket wsock32; do
+for ac_lib in '' socket ws2_32; do
if test -z $ac_lib; then
ac_res=none required
else
diff --git a/configure.in b/configure.in
index 7dfbe9f..01bbe05 100644
--- a/configure.in
+++ b/configure.in
@@ -892,7 +892,7 @@ fi
AC_CHECK_LIB(m, main)
AC_SEARCH_LIBS(setproctitle, util)
AC_SEARCH_LIBS(dlopen, dl)
-AC_SEARCH_LIBS(socket, [socket wsock32])
+AC_SEARCH_LIBS(socket, [socket ws2_32])
AC_SEARCH_LIBS(shl_load, dld)
# We only use libld in port/dynloader/aix.c
case $host_os in
diff --git a/contrib/pgcrypto/Makefile b/contrib/pgcrypto/Makefile
index 1c85c98..4d91a06 100644
--- a/contrib/pgcrypto/Makefile
+++ b/contrib/pgcrypto/Makefile
@@ -54,7 +54,7 @@ SHLIB_LINK += $(filter -lcrypto -lz, $(LIBS))
ifeq ($(PORTNAME), win32)
SHLIB_LINK += $(filter -leay32, $(LIBS))
# those must be at the end
-SHLIB_LINK += -lwsock32 -lws2_32
+SHLIB_LINK += -lws2_32
endif
rijndael.o: rijndael.tbl
diff --git a/src/interfaces/libpq/Makefile b/src/interfaces/libpq/Makefile
index 15ea648..718ecd6 100644
--- a/src/interfaces/libpq/Makefile
+++ b/src/interfaces/libpq/Makefile
@@ -70,7 +70,7 @@ else
SHLIB_LINK += $(filter -lcrypt -ldes -lcom_err -lcrypto -lk5crypto -lkrb5 -lgssapi32 -lssl -lsocket -lnsl -lresolv -lintl $(PTHREAD_LIBS), $(LIBS)) $(LDAP_LIBS_FE)
endif
ifeq ($(PORTNAME), win32)
-SHLIB_LINK += -lshfolder -lwsock32 -lws2_32 -lsecur32 $(filter -leay32 -lssleay32 -lcomerr32 -lkrb5_32, $(LIBS))
+SHLIB_LINK += -lshfolder -lws2_32 -lsecur32 $(filter -leay32 -lssleay32 -lcomerr32 -lkrb5_32, $(LIBS))
endif
SHLIB_EXPORTS = exports.txt
diff --git a/src/interfaces/libpq/win32.c b/src/interfaces/libpq/win32.c
index 88d12d6..c0fe0fb 100644
--- a/src/interfaces/libpq/win32.c
+++ b/src/interfaces/libpq/win32.c
@@ -248,9 +248,6 @@ struct MessageDLL
winsock.dll, 0, 0
},
{
- wsock32.dll, 0, 0
- },
- {
ws2_32.dll, 0, 0
},
{
diff --git a/src/interfaces/libpq/win32.mak b/src/interfaces/libpq/win32.mak
index 23e09e9..99fef27 100644
--- a/src/interfaces/libpq/win32.mak
+++ b/src/interfaces/libpq/win32.mak
@@ -208,7 +208,7 @@ CPP_SBRS=.
RSC_PROJ=/l 0x409 /fo$(INTDIR)\libpq.res
LINK32=link.exe
-LINK32_FLAGS=kernel32.lib user32.lib advapi32.lib shfolder.lib wsock32.lib ws2_32.lib secur32.lib $(SSL_LIBS) $(KFW_LIB) $(ADD_SECLIB) \
+LINK32_FLAGS=kernel32.lib user32.lib advapi32.lib shfolder.lib ws2_32.lib secur32.lib $(SSL_LIBS) $(KFW_LIB) $(ADD_SECLIB) \
/nologo /subsystem:windows /dll $(LOPT) /incremental:no \
/pdb:$(OUTDIR)\libpqdll.pdb /machine:$(CPU) \
/out:$(OUTDIR)\$(OUTFILENAME).dll\
diff --git a/src/test/thread/README b/src/test/thread/README
index 00ec2ff..4da2344 100644
--- a/src/test/thread/README
+++ b/src/test/thread/README
@@ -40,7 +40,7 @@ to test your system however, you can do so as follows:
-D_POSIX_PTHREAD_SEMANTICS \
-I../../../src/include/port/win32 \
thread_test.c \
--lwsock32 \
+-lws2_32 \
-lpthreadgc2
3) Run thread_test.exe. You should see output like:
diff --git a/src/tools/msvc/Mkvcbuild.pm b/src/tools/msvc/Mkvcbuild.pm
index 8002f23..0f63491 100644
--- a/src/tools/msvc/Mkvcbuild.pm
+++ b/src/tools/msvc/Mkvcbuild.pm
@@ -44,7 +44,7 @@ my @contrib_uselibpgcommon = (
'pg_test_fsync', 'pg_test_timing',
'pg_upgrade','pg_xlogdump',
'vacuumlo');
-my $contrib_extralibs = { 'pgbench' = ['wsock32.lib'] };
+my $contrib_extralibs = {
Re: [HACKERS] Removing dependency to wsock32.lib when compiling code on WIndows
From: Michael Paquier michael.paqu...@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
Re: [HACKERS] Removing dependency to wsock32.lib when compiling code on WIndows
On Thu, Jun 19, 2014 at 11:13 PM, MauMau maumau...@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
Re: [HACKERS] Removing dependency to wsock32.lib when compiling code on WIndows
From: Michael Paquier michael.paqu...@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
Re: [HACKERS] Removing dependency to wsock32.lib when compiling code on WIndows
On Mon, Apr 21, 2014 at 12:54 PM, Michael Paquier michael.paqu...@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
[HACKERS] Removing dependency to wsock32.lib when compiling code on WIndows
Hi all,
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?
Regards,
--
Michael
commit 805e63f0c06c55c7133e9b42a2b57597d1f45494
Author: Michael Paquier mich...@otacoo.com
Date: Mon Apr 21 12:48:30 2014 +0900
Replace wsock32.lib by ws2_32.lib in mkvc spec for Windows build
wsock32.lib is the Windows socket library, an older and obsolete version
of ws2_32.lib.
diff --git a/src/tools/msvc/Mkvcbuild.pm b/src/tools/msvc/Mkvcbuild.pm
index 308a4b4..63d457e 100644
--- a/src/tools/msvc/Mkvcbuild.pm
+++ b/src/tools/msvc/Mkvcbuild.pm
@@ -44,7 +44,7 @@ my @contrib_uselibpgcommon = (
'pg_test_fsync', 'pg_test_timing',
'pg_upgrade','pg_xlogdump',
'vacuumlo');
-my $contrib_extralibs = { 'pgbench' = ['wsock32.lib'] };
+my $contrib_extralibs = { 'pgbench' = ['ws2_32.lib'] };
my $contrib_extraincludes =
{ 'tsearch2' = ['contrib/tsearch2'], 'dblink' = ['src/backend'] };
my $contrib_extrasource = {
@@ -113,9 +113,8 @@ sub mkvcbuild
$postgres-AddFiles('src\backend\replication', 'repl_scanner.l',
'repl_gram.y');
$postgres-AddDefine('BUILDING_DLL');
- $postgres-AddLibrary('wsock32.lib');
- $postgres-AddLibrary('ws2_32.lib');
$postgres-AddLibrary('secur32.lib');
+ $postgres-AddLibrary('ws2_32.lib');
$postgres-AddLibrary('wldap32.lib') if ($solution-{options}-{ldap});
$postgres-FullExportDLL('postgres.lib');
@@ -270,7 +269,6 @@ sub mkvcbuild
$libpq-AddDefine('FRONTEND');
$libpq-AddDefine('UNSAFE_STAT_OK');
$libpq-AddIncludeDir('src\port');
- $libpq-AddLibrary('wsock32.lib');
$libpq-AddLibrary('secur32.lib');
$libpq-AddLibrary('ws2_32.lib');
$libpq-AddLibrary('wldap32.lib') if ($solution-{options}-{ldap});
@@ -300,7 +298,7 @@ sub mkvcbuild
$libecpg-AddIncludeDir('src\interfaces\libpq');
$libecpg-AddIncludeDir('src\port');
$libecpg-UseDef('src\interfaces\ecpg\ecpglib\ecpglib.def');
- $libecpg-AddLibrary('wsock32.lib');
+ $libecpg-AddLibrary('ws2_32.lib');
$libecpg-AddReference($libpq, $pgtypes, $libpgport);
my $libecpgcompat = $solution-AddProject(
@@ -345,7 +343,7 @@ sub mkvcbuild
$isolation_tester-AddIncludeDir('src\interfaces\libpq');
$isolation_tester-AddDefine('HOST_TUPLE=i686-pc-win32vc');
$isolation_tester-AddDefine('FRONTEND');
- $isolation_tester-AddLibrary('wsock32.lib');
+ $isolation_tester-AddLibrary('ws2_32.lib');
$isolation_tester-AddReference($libpq, $libpgcommon, $libpgport);
my $pgregress_isolation =
@@ -363,7 +361,6 @@ sub mkvcbuild
$initdb-AddIncludeDir('src\interfaces\libpq');
$initdb-AddIncludeDir('src\timezone');
$initdb-AddDefine('FRONTEND');
- $initdb-AddLibrary('wsock32.lib');
$initdb-AddLibrary('ws2_32.lib');
my $pgbasebackup = AddSimpleFrontend('pg_basebackup', 1);
@@ -500,7 +497,7 @@ sub mkvcbuild
'pgp-mpi-internal.c', 'imath.c');
}
$pgcrypto-AddReference($postgres);
- $pgcrypto-AddLibrary('wsock32.lib');
+ $pgcrypto-AddLibrary('ws2_32.lib');
my $mf = Project::read_file('contrib/pgcrypto/Makefile');
GenerateContribSqlFiles('pgcrypto', $mf);
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
