Closed ghost closed 5 years ago
Solution: I had to put #define _WIN32_WINNT 0x0501 in first line (before all includes).
It is, in fact, supposed to work out of the box. That it doesn't means that something has changed between the MinGW version you use and the ones on which we have tested the library.
The problem is likely to be a different default Windows version. If this is the case, we can almost certainly give a more useful diagnostic when problems occur.
If you do not define _WIN32_WINNT
, what value is assigned to it when you include <windows.h>
(if any)?
Without '#include "mingw.thread.h"' and '#define _WIN32_WINNT 0x0501', and writing '#include
I have laptop from work, so I am guessing that my Windows are modified by company's IT so that some OS function are private, some disabled, ..., which is why this wrapper didn't work out of the box. Just a guess though.
Your version of MinGW has a default target Windows version of Windows 2000 (which didn't have thread support). This is good to know; it means we can check both for when a user requests to target an unsupported Windows version, and for when the default is insufficient. In either case, an error should be raised, though the latter case could also be extended to give performance hints such as "Select a target of Windows 7 for better performance. Here's how."
When MinGW, MSVC, etc. are configured to target a version of Windows before Windows XP, the system header windows.h
typically will not include the signatures of functions not provided by the system. In the case of Windows 2000, those missing signatures include many of the functions vital for this library, such as functions used to join threads.
I expect to submit a PR with the errors/hints soon.
Thank you very much for your help, hope this bug (?) will be solved.
BTW, what is the version of your MinGW? You can check by invoking the compiler with the --version
flag.
Thank you very much for your help, hope this bug (?) will be solved.
It's not a bug, despite appearances. Your version of MinGW is configured to select Windows 2000 by default, and this is simply insufficient to support this library. This library depends on Windows XP features, and makes that explicit in the README. This library will also benefit from later versions; targeting Windows 7, for example, will improve the performance of condition_variable
s and mutex
es.
Ideally, we would check whether _WIN32_WINNT
is defined before including <windows.h>
, and define it ourselves if it were not. However, we would need to make sure that the value we set is not less than the version that MinGW would use by default (a potentially-difficult process, as power-users may have set the default themselves when building MinGW).
@alxvasilev's question about the version of MinGW you are using is probably intended for this purpose. If we can determine the version of MinGW at which the default Windows target was first changed to Windows XP, we can use that information to adjust the default whenever it would be insufficient.
BTW, what is the version of your MinGW? You can check by invoking the compiler with the
--version
flag.
Sorry for late reply, I was sick. Is this what you are asking?
I have same problem. windows 10. gcc (GCC) 7.3.0
I download the zip file, unzip them to mingw\include folder using C::B 17.12 in compiler setting:->#defines: _WIN32_WINNT=0x0A00 add one line to test.cpp
Lots error.
mingw.mutex.h|162|error: 'SRWLOCK_INIT' was not declared in this scope|
mingw.mutex.h||In member function 'void mingw_stdthread::recursive_timed_mutex::lock()':|
mingw.mutex.h|324|error: 'owner_dead' is not a member of 'std::errc'|
mingw.mutex.h|325|error: 'protocol_error' is not a member of 'std::errc'|
mingw.shared_mutex.h|73|error: 'CHAR_BIT' was not declared in this scope|
mingw.condition_variable.h|264|error: 'CONDITION_VARIABLE_INIT' was not declared in this scope|
mingw.condition_variable.h||In member function 'bool mingw_stdthread::vista::condition_variable::wait_unique(mingw_stdthread::windows7::mutex, DWORD)':|
mingw.condition_variable.h|312|error: 'CONDITION_VARIABLE_LOCKMODE_SHARED' was not declared in this scope|
mingw.condition_variable.h||In member function 'bool mingw_stdthread::vista::condition_variable_any::wait_impl(mingw_stdthread::shared_lock
@changshen In one case (error: 'CHAR_BIT' was not declared in this scope
) it is a problem with the library itself, and will be fixed shortly (#51).
In other cases, the source is not obvious, and I have not been able to replicate the error. In particular, error: 'SRWLOCK_INIT' was not declared in this scope
and the like are not occurring. If you can prepare an example where that occurs (including the .cbp
file and all changes you made), it will be quite helpful.
In yet other cases, the problem is with your compiler settings. For example, the error mingw.mutex.h|324|error: 'owner_dead' is not a member of 'std::errc'
(and most of the other errors you encounter) should only appear if you are compiling for a version of C++ earlier than C++11. I'm not sure why you're not encountering the #error
commands that are intended to warn about this, but perhaps we can determine that shortly.
Thanks Dr. McClatchey
in C:B I checked compiler option to use c++11.
I just created a console project, replace main.cpp with the test.cpp code. add #include
@changshen I am pressed for time, right now, but I'll be able to investigate this in more detail next Thursday (February 28th). I hope you will be available to provide feedback as we explore the exact reasons for the errors that occurred.
Before then, try eliminating all #include "mingw.*.h"
lines and the code specific to the MinGW std threads library (leave only logging statements in the test file). If my intuition is correct, this will still fail to compile, despite not interacting with the threading library. If even a pared-down test file does not compile, the error messages produced should give further insight into the problem you are encountering.
The remaining errors (not warnings) should be resolved by 079f9e6 . That commit changes handling of mutexes, and replaces the standard-library error codes with direct copies of the error codes that Windows supplies. It also alters behavior in the event of a recursive_mutex_*
being accessed after a thread that holds it is terminated.
I have MingW on Windows 10. That windows.h in MinGW returns value as 0x500 Win version HEX = 0x500; WINVER = 0x500; WINNTVER(NTDDI_VERSION) = 0x500. Is that mean MinGW for windows 10 does not support threading? When I define global compiler settigns->#define with"_WIN32_WINNT=0x0700" I got compilation error: (code::block version 17.12, ) mingw.mutex.h |176 | error: 'SRWLOCK_INIT' was not declared in this scope mingw.condition_variable.h | 278 | error: 'CONDITION_VARIABLE_INIT' was not declared in this scope mingw.condition_variable.h | 326 | error: 'CONDITION_VARIABLE_LOCKMODE_SHARED' was not declared in this scope My Gcc compiler version: g++ (MinGW.org GCC-8.2.0-3) 8.2.0 Copyright (C) 2018 Free Software Foundation, Inc. comiler option is: mingw32-g++.exe -Wall -std=c++14 -fPIC -m32 -fexceptions -g -D_WIN32_WINNT=0x0700
update: I added those line to test,cpp and it compiles. Those variables are defined in windows visual studio c++ headers. But I am using MinGW so those headers are not in the search path. How to handle those correctly?
unsigned long CONDITION_VARIABLE_LOCKMODE_SHARED = RTL_CONDITION_VARIABLE_LOCKMODE_SHARED;
I downloaded and ran tests.cpp file in codeblocks, and I get a bunch of error, first being '::GetNativeSystemInfo has not been declared'. I suppose I have wrong mingw version, since this implementation of standard threads doesnt work out of the box?