-
Notifications
You must be signed in to change notification settings - Fork 227
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MinGW + MSYS Build Issue #63
Comments
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 |
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
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
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). |
These look like some simple missing type definitions... For example, I think |
I know building Boost with MinGW64 can be a pain... But if there's some standard Windows header that defines |
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 Once you comment out For now I went ahead and used libpq as my use case was relatively small and I needed to continue on my project. |
I wonder if maybe I should use WSAPoll only if the platform is Windows and the compiler is Visual C++. |
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 |
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 |
I don't think it's a big problem to use |
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 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. |
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 |
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. |
OK, thanks! |
Sorry if this isn't the right place for this, but my build is failing during the make on Windows in the MinGW and MSYS environment.
Obviously the mstcpip header is missing, but I don't see this header in a clean MinGW installation. I see it in my MinGW-w64 installation and in Windows itself (Windows Kits). Is there a work around for this?
The text was updated successfully, but these errors were encountered: