MinGW + MSYS Build Issue

[jtv]

MinGW + MSYS Build Issue

[jtv]

As far as I know it's a native Windows header, so I don't know why MinGW would have its own copy.

Have you tried (a) using the MinGW-w64 copy, or (b) using the Windows Kits copy, or even (c) commenting out that #include line?

[maspe36]

MinGW headers are just a reimplementation of native win32 headers. Just dumping the MinGW-w64 or Window Kits headers didn't work. And commenting out doesn't work either. All 3 options have the same issue

$ make
Making all in include
make[1]: Entering directory `/home/Sam/libpqxx-6.0.0/include'
Making all in pqxx
make[2]: Entering directory `/home/Sam/libpqxx-6.0.0/include/pqxx'
make  all-am
make[3]: Entering directory `/home/Sam/libpqxx-6.0.0/include/pqxx'
make[3]: Leaving directory `/home/Sam/libpqxx-6.0.0/include/pqxx'
make[2]: Leaving directory `/home/Sam/libpqxx-6.0.0/include/pqxx'
make[2]: Entering directory `/home/Sam/libpqxx-6.0.0/include'
make[2]: Nothing to be done for `all-am'.
make[2]: Leaving directory `/home/Sam/libpqxx-6.0.0/include'
make[1]: Leaving directory `/home/Sam/libpqxx-6.0.0/include'
Making all in src
make[1]: Entering directory `/home/Sam/libpqxx-6.0.0/src'
/bin/sh ../libtool  --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H   -I../include -I../include -Ic:/PROGRA~2/PostgreSQL/9.6/include   -g -O2 -fvisibility=hidden -fvisibility-inlines-hidden -MT connection_base.lo -MD -MP -MF .deps/connection_base.Tpo -c -o connection_base.lo connection_base.cxx
libtool: compile:  g++ -DHAVE_CONFIG_H -I../include -I../include "-Ic:/PROGRA~2/PostgreSQL/9.6/include" -g -O2 -fvisibility=hidden -fvisibility-inlines-hidden -MT connection_base.lo -MD -MP -MF .deps/connection_base.Tpo -c connection_base.cxx -o connection_base.o
connection_base.cxx: In function 'void {anonymous}::wait_fd(int, bool, timeval*)':
connection_base.cxx:1166:36: error: 'POLLWRNORM' was not declared in this scope
   const short events = (forwrite ? POLLWRNORM : POLLRDNORM);
                                    ^~~~~~~~~~
connection_base.cxx:1166:49: error: 'POLLRDNORM' was not declared in this scope
   const short events = (forwrite ? POLLWRNORM : POLLRDNORM);
                                                 ^~~~~~~~~~
connection_base.cxx:1167:3: error: 'WSAPOLLFD' was not declared in this scope
   WSAPOLLFD fdarray{SOCKET(fd), events, 0};
   ^~~~~~~~~
connection_base.cxx:1168:12: error: 'fdarray' was not declared in this scope
   WSAPoll(&fdarray, 1, tv_milliseconds(tv));
            ^~~~~~~
connection_base.cxx:1168:43: error: 'WSAPoll' was not declared in this scope
   WSAPoll(&fdarray, 1, tv_milliseconds(tv));
                                           ^

After some digging I noticed this is defined in WinSock2.h in MinGW-w64 and the Windows Kit version of the header but not in the MinGW header. Simply grabbing that def and slotting it into MinGW doesn't work and gives me

$ make
Making all in include
make[1]: Entering directory `/home/Sam/libpqxx-6.0.0/include'
Making all in pqxx
make[2]: Entering directory `/home/Sam/libpqxx-6.0.0/include/pqxx'
make  all-am
make[3]: Entering directory `/home/Sam/libpqxx-6.0.0/include/pqxx'
make[3]: Leaving directory `/home/Sam/libpqxx-6.0.0/include/pqxx'
make[2]: Leaving directory `/home/Sam/libpqxx-6.0.0/include/pqxx'
make[2]: Entering directory `/home/Sam/libpqxx-6.0.0/include'
make[2]: Nothing to be done for `all-am'.
make[2]: Leaving directory `/home/Sam/libpqxx-6.0.0/include'
make[1]: Leaving directory `/home/Sam/libpqxx-6.0.0/include'
Making all in src
make[1]: Entering directory `/home/Sam/libpqxx-6.0.0/src'
/bin/sh ../libtool  --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H   -I../include -I../include -Ic:/PROGRA~2/PostgreSQL/9.6/include   -g -O2 -fvisibility=hidden -fvisibility-inlines-hidden -MT connection_base.lo -MD -MP -MF .deps/connection_base.Tpo -c -o connection_base.lo connection_base.cxx
libtool: compile:  g++ -DHAVE_CONFIG_H -I../include -I../include "-Ic:/PROGRA~2/PostgreSQL/9.6/include" -g -O2 -fvisibility=hidden -fvisibility-inlines-hidden -MT connection_base.lo -MD -MP -MF .deps/connection_base.Tpo -c connection_base.cxx -o connection_base.o
connection_base.cxx:43:5: error: 'SOCKET' does not name a type
     SOCKET  fd;
     ^~~~~~
connection_base.cxx:44:5: error: 'SHORT' does not name a type
     SHORT   events;
     ^~~~~
connection_base.cxx:45:5: error: 'SHORT' does not name a type
     SHORT   revents;
     ^~~~~
connection_base.cxx:47:31: error: expected initializer before '*' token
 } WSAPOLLFD, *PWSAPOLLFD, FAR *LPWSAPOLLFD;
                               ^
connection_base.cxx: In function 'void {anonymous}::wait_fd(int, bool, timeval*)':
connection_base.cxx:1193:42: error: too many initializers for 'WSAPOLLFD {aka pollfd}'
   WSAPOLLFD fdarray{SOCKET(fd), events, 0};
                                          ^
connection_base.cxx:1194:43: error: 'WSAPoll' was not declared in this scope
   WSAPoll(&fdarray, 1, tv_milliseconds(tv));
                                           ^

I can try swapping back to the MinGW-w64 compiler for my project since its a lot closer to completely reimplementing the Windows API. But this will take some time (rebuilding boost) and using their gdb was causing a segfault on my system (which is why I swapped to MinGW in the first place).

[jtv]

These look like some simple missing type definitions... For example, I think SOCKET was simply an alias for int or short. Surely these are defined in some standard header somewhere?

[jtv]

I know building Boost with MinGW64 can be a pain... But if there's some standard Windows header that defines SOCKET, SHORT, WSAPOLLFD, and so on, then I could just include that.

[maspe36]

So as I understand it, when you use MinGW to compile it doesn't look at native windows headers. It looks at re-implemented headers in the <MinGW installation>\include folder. The first issue is in this MinGW include folder there is no mstcpip.h header. This is probably because the base MinGW project moves really slow and has less headers re-implemented than the MinGW-w64 project which does have this header in its include folder <MinGW64 installation>\mingw64\x86_64-w64-mingw32\include.

Once you comment out #include <mstcpip.h> in connection_base.cxx you start seeing these missing def's (see the first output I pasted). I hunted it down and found the def's for POLLWRNORM and POLLRDNORM in MinGW-w64's winsock2.h but I did not find it in MinGW's winsock2.h. My next step was to try and just grab MinGW-w64's entire winsock2.h and replace the default one in MinGW (see the second output I pasted).

For now I went ahead and used libpq as my use case was relatively small and I needed to continue on my project.

[jtv]

I wonder if maybe I should use WSAPoll only if the platform is Windows and the compiler is Visual C++.

[elelel]

According to Wikipedia "The development of the original MinGW project has halted in 2013, but an alternative called MinGW-w64 has been created by a different author to include several new APIs and provide 64-bit support.", so it's not that it just moves slowly. It's unlikely to see unimplemented API there. The easiest way to compile projects involving mingwXX/libpqxx it to use MSYS2. There you have libpqxx precompiled, as well as boost, compatible gdb, etc. And of course you can build libpqxx there yourself, in fact it's even easier than to build it on Windows using nmake/MS compiler.

Correction: sorry, I'm completely wrong, tried to compile the latest master for i686 target and have the same problem :( The file mstcpip.h file however exists in their version of Mingw32

[elelel]

I made a fix, and it won't try to compile WSAPoll on Windows version on which it is not supposed to exist. But when compiling on Windows 10/MSYS2/MINGW i686 autotools configuration script don't set correct _WIN32_WINNT value, so you get a suboptimal executable, unless you set _WIN32_WINNT manually to 0x0600. If you set it manually, libpqxx compiles correctly with WSAPoll on msys2/mingw32

[jtv]

I don't think it's a big problem to use select() instead of WSAPoll when both are available.

[elelel]

WSAPoll theoretically is more efficient under high loads. Multiplatform compiled project that take advantage of it usually add a detection by the build system, e.g. for CMake: https://stackoverflow.com/questions/9742003/platform-detection-in-cmake
Non-compiled projects (header-only library) usually include a warning using C macros like this:
https://github.com/chriskohlhoff/asio/blob/b0926b61b057ce563241d609cae5768ed3a4e1b1/asio/include/asio/detail/config.hpp#L903

I think it makes sense to add such a warning if the platform is Windows and _WIN32_WINNT is not defined at all. As for detection by build system, I am not sure if it is possible to achieve with autotools.

[jtv]

This is exactly the kind of thing that autoconf was made for. The problem, I think, is that most Windows users probably won't be running a configure script. I'm not too keen on adding a warning, but if it really turns out to matter then at that point we can see about improving detection.

So if your patch means that "native" Windows builds get WSAPoll, and "non-native" Windows builds like yours get select, then I think we can close this bug, right?

[elelel]

I'm not sure that it really matters, in fact I personally think that the whole idea behind WSAPoll was just to provide poll()-like interface to Windows developers. But some people say it is faster under certain conditions.
My patch reflects the requirement from Mingw32 windows header files, the check is hardcoded there. I did not look into the native headers, but I guess they must be the same. If there's no problem with that with native builds (e.g. MSVC/nmake) that could be because these systems set the define to current win version if it's not defined, or it can be because their headers don't use this particular variant of platform compatibility check for WSAPoll. In any case I'm just pointing it out for your considiration, this is not to in any way to prevent you from closing this bug :)

[jtv]

OK, thanks!