'mutex' is not a member of 'std' in MinGW 5.3.0

Question

I am using MinGW 5.3.0 and Crypto++ 5.6.5:

C:\MinGW>g++ -std=c++11 -s -D_WIN32_WINNT=0x0501 LOG.cpp -U__STRICT_ANSI__ Decclass.cpp \
-IC:\\MinGW\\ -IC:\\MinGW\\boost -LC:\\MinGW  -lssl -lcrypto -lcryptopp -lgdi32 -lPCRYPT \
 -lz -ltiny -lwsock32 -lws2_32 -lShlwapi

Compiling results in the error below.

c:\mingw\cryptopp565\include\cryptopp\misc.h:287:14: error: 'mutex' in namespace 'std'
does not name a typestatic std::mutex s_mutex;

c:\mingw\cryptopp565\include\cryptopp\misc.h:296:18: error: 'mutex' is not a member of
'std'std::lock_guard<std::mutex> lock(s_mutex);

It showing 'mutex' is not a member of 'std'

Do i need anther version of MinGW ? Or can I fix this build itself?

Crypto++ 5.6.4 and above includes ``, but it guards the inclusion based on the compiler. See [`stdcpp.h` from 5.6.4](https://github.com/weidai11/cryptopp/blob/4132d85888ac6c30729f58bb442a4a26a5b16cfe/stdcpp.h). That inclusion may need to be tuned if MinGW does not offer it. We don't see a lot of MinGW testing because it was abandoned some time ago and very few people appear to use it. (I can't tell what's going on because I can't read the text in your picture. You should post the actual text). — jww, May 09 '17 at 18:03
See https://stackoverflow.com/questions/17242516/mingw-w64-threads-posix-vs-win32 — rogerdpack, Oct 25 '18 at 06:09

score 3 · Accepted Answer · answered May 10 '17 at 12:36

3

I fix this issue by editing "misc.h" in the path "cryptopp565\include\cryptopp\misc.h"

On the top of misc.h I included the mutex.hpp from boost library

#include "c:\mingw\include\boost\asio\detail\mutex.hpp"

and i changed namespace also from std to boost::asio::detail

static std::mutex s_mutex; 
static boost::asio::detail::mutex s_mutex;

answered May 10 '17 at 12:36

Amit.Desai

155
1
12

I suggest you visit `config.h`, and ensure the define `CRYPTOPP_CXX11_SYNCHRONIZATION` is not defined for your configuration. – jww May 13 '17 at 03:24

score 0 · Answer 2 · answered Mar 12 '21 at 13:42

MINGW supports std::thread and std::mutex with POSIX threads only, definitely a gap of the non-POSIX-release.

Now, you do not switch your development environment for a single program.

Options are to build stubs from POSIX specific templates (those code branches selected by _GLIBCXX_HAS_GTHREADS) or MS-Sources or BOOST library ...

score -1 · Answer 3 · edited Oct 25 '18 at 14:58

I think we may have mostly cleared this MinGW/C++11 issue at cryptopp Commit e4cef84883b2. You should work from Master or perform a git pull, and then uncomment the define for CRYPTOPP_NO_CXX11 in config.h : 65 (or so):

// Define CRYPTOPP_NO_CXX11 to avoid C++11 related features shown at the
// end of this file. Some compilers and standard C++ headers advertise C++11
// but they are really just C++03 with some additional C++11 headers and
// non-conforming classes. You might also consider `-std=c++03` or
// `-std=gnu++03`, but they are required options when building the library
// and all programs. CRYPTOPP_NO_CXX11 is probably easier to manage but it may
// cause -Wterminate warnings under GCC. MSVC++ has a similar warning.
// Also see https://github.com/weidai11/cryptopp/issues/529
// #define CRYPTOPP_NO_CXX11 1

I think the problems is, you are hitting issues related to Windows and its lack of proper C++11 support, but you are getting them indirectly. They are indirect because MinGW and GCC is layered on top. MinGW and GCC cannot possibly provide C++11 because the underlying platform cannot.

I think your best bet at this point is to define CRYPTOPP_NO_CXX11. I don't believe we can do it for you like we do on Windows because the defines we need access to are hidden behind MinGW and GCC. And we also have some MSVC++ bugs to workaround.

Here's how we do it on Windows, but we don't have access to these defines in MinGW (from config.h : 950):

// Dynamic Initialization and Destruction with Concurrency ("Magic Statics")
// MS at VS2015 with Vista (19.00); GCC at 4.3; LLVM Clang at 2.9; Apple Clang at 4.0; Intel 11.1; SunCC 5.13.
// Microsoft's implementation only works for Vista and above, so its further
// limited. http://connect.microsoft.com/VisualStudio/feedback/details/1789709
#if (CRYPTOPP_MSC_VERSION >= 1900) && ((WINVER >= 0x0600) || (_WIN32_WINNT >= 0x0600)) || \
    (CRYPTOPP_LLVM_CLANG_VERSION >= 20900) || (CRYPTOPP_APPLE_CLANG_VERSION >= 40000) || \
    (__INTEL_COMPILER >= 1110) || (CRYPTOPP_GCC_VERSION >= 40300) || (__SUNPRO_CC >= 0x5130)
# define CRYPTOPP_CXX11_DYNAMIC_INIT 1
#endif // Dynamic Initialization compilers

If you define CRYPTOPP_NO_CXX11, then the following will not be defined and you will avoid the problems: CRYPTOPP_CXX11_DYNAMIC_INIT, CRYPTOPP_CXX11_SYNCHRONIZATION, and CRYPTOPP_CXX11_ATOMICS.

Question od which mingw he uses. In fact there is c++17 AVAILABLE.Thing is that old MinGW thread devs did not want to imple,ent thing for x64 bit platform. — Swift - Friday Pie, Oct 25 '18 at 15:08
The underlying platform has nothing to do with what a language implementation can provide. If you use a MinGW-w64 compiler with "posix threading" you will get access to `std::mutex`, `std::thread` and the like. The real issue here is that MinGW 5.3.0 is wholly outdated. — rubenvb, Oct 25 '18 at 15:10
I managed to use std::mutex with 4.92. I think the key is missing -mthreads flag. mutex header is guarded by several preprocessor conditions. — Swift - Friday Pie, Oct 25 '18 at 15:18

'mutex' is not a member of 'std' in MinGW 5.3.0

3 Answers3

Linked