Open CommanderBubble opened 4 years ago
just tested same build for 4.3.1, the issue does not exist there
Looking at condition_variable.hpp, the checking around windows changed between releases. The check for which version is now done by cmake, setting (in my particular case) the variable ZMQ_USE_CV_IMPL_STL11 to 1, and for some reason this is not able to build.
I've encountered the same issue in libzmq version 4.3.3:
This issue has been automatically marked as stale because it has not had activity for 365 days. It will be closed if no further activity occurs within 56 days. Thank you for your contributions.
same issue with 4.3.4
I ended up on this issue due to having a similar issue on AIX. For other people in the same boat, make sure you have -pthread
in your CFLAGS
, CXXFLAGS
, and LDFLAGS
. -lpthread
isn't sufficient on AIX, and C++ types depending on threading won't be present.
I am having the same issue
I was able to move past this issue by reverting to 4.3.1 as @CommanderBubble said! Version 4.3.4 also has this issue.
Any updates here? I'm running into the same issue while building the Windows Ruby gems for czmq-ffi-gen.
I'm using v4.3.5
...
[ 25%] Building CXX object CMakeFiles/libzmq.dir/src/msg.cpp.obj
[ 25%] Building CXX object CMakeFiles/libzmq-static.dir/src/epoll.cpp.obj
In file included from /czmq-ffi-gen/vendor/libzmq/src/mailbox_safe.hpp:16,
from /czmq-ffi-gen/vendor/libzmq/src/mailbox_safe.cpp:4:
/czmq-ffi-gen/vendor/libzmq/src/condition_variable.hpp:102:10: error: 'condition_variable_any' in namespace 'std' does not name a type
102 | std::condition_variable_any _cv;
| ^~~~~~~~~~~~~~~~~~~~~~
/czmq-ffi-gen/vendor/libzmq/src/condition_variable.hpp:71:1: note: 'std::condition_variable_any' is defined in header '<condition_variable>'; did you forget to '#include <condition_variable>'?
70 | #include <condition_variable>
+++ |+#include <condition_variable>
71 |
The suggestion about including <condition_variable>
is already in src/condition_variable.hpp.
Docker image: Ubuntu 22.04 (building for mingw)
Version 4.3.5 Cross-compile from Debian to MinGW using the MinGW suit.
If anyone has encountered this, I solved it by using ./configure --with-cv-impl=pthread .....
Issue description
Building on Windows with MinGW_w64 fails when using Win32 threading model, using CMake and Ninja
Environment
Minimal test code / Steps to reproduce the issue
make MinGW w64 gcc with WIN32 threading model detected compiler build using CMake and Ninja.
What's the actual result? (include assertion message & call stack if applicable)
What's the expected result?
The build should be able to succeed or