Re: error: 'mutex' in namespace 'std' does not name a type

2017-11-08 Thread Marcel Raad
Am 08.11.2017 00:29 schrieb "Jeffrey Walton" :

The 32-bit prompt looks off to me. It says MINGW32 as expected, but the
compiler is building for (targeting) 64-bit executable:

test@asus-windows MINGW32 ~/cryptopp
$ uname -a
MINGW32_NT-6.3 asus-windows8 2.9.0(0.318/5/3) 2017-09-13 23:16 x86_64
Msys

test@asus-windows MINGW32 ~/cryptopp
$ gcc -dumpmachine
x86_64-pc-msys

Those outputs look wrong to me for a 32-bit machine.


That's really odd. Mine says:
MINGW32 ~
$ gcc -dumpmachine
i686-w64-mingw32

Yours is from the MSYS compiler:
MSYS ~
$ gcc -dumpmachine
x86_64-pc-msys

Marcel

-- 
-- 
You received this message because you are subscribed to the "Crypto++ Users" 
Google Group.
To unsubscribe, send an email to cryptopp-users-unsubscr...@googlegroups.com.
More information about Crypto++ and this group is available at 
http://www.cryptopp.com.
--- 
You received this message because you are subscribed to the Google Groups 
"Crypto++ Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cryptopp-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: error: 'mutex' in namespace 'std' does not name a type

2017-11-07 Thread Jeffrey Walton
On Tue, Nov 7, 2017 at 1:53 PM,   wrote:
> Here are three more experiments building three different CryptoPP versions
> with the latest 64-bit/64-bit MingW compiler.
>
> Since I already have a solution, this should have no sense of urgency.  Let
> me know if there is something specific I can do to help.

It looks like 3 different issues.

> I fixed my compiler version.  Now it is a 64-bit application and targeting
> 64-bit:
>
> C:\data\code\experimental\cryptopp562>g++ -v
> Using built-in specs.
> COLLECT_GCC=g++
> ...
>
> COMPILING CRYPTOPP562 has this error:
> g++ -DNDEBUG -g -O2 -march=native -DCRYPTOPP_DISABLE_ASM -pipe -c wake.cpp
> wake.cpp: In member function 'void
> CryptoPP::WAKE_Base::GenKey(CryptoPP::word32, CryptoPP::word32,
> CryptoPP::word32, CryptoPP::word32)':
> wake.cpp:34:15: error: narrowing conversion of '3868867420' from 'unsigned
> int' to 'int' inside { } [-Wnarrowing]
>0x9ee27cf3, } ;
>^
> wake.cpp:34:15: error: narrowing conversion of '3553042405' from 'unsigned
> int' to 'int' inside { } [-Wnarrowing]
> wake.cpp:34:15: error: narrowing conversion of '2872865746' from 'unsigned
> int' to 'int' inside { } [-Wnarrowing]
> wake.cpp:34:15: error: narrowing conversion of '2665643251' from 'unsigned
> int' to 'int' inside { } [-Wnarrowing]
> make: *** [wake.o] Error 1

This looks like our bug that surfaces under MinGW. In the past the
signed type was changed to an unsigned type, which squashed most
problems. I guess we need to do a little more.

https://github.com/weidai11/cryptopp/blob/master/wake.cpp

> COMPILING CRYPTOPP565 gives a weird error and pops up a crash dialog:
> g++ -o cryptest.exe -DNDEBUG -g2 -O2 --std=c++11 -march=native -pipe test.o
> bench1.o bench2.o validat1.o validat2.o validat3.o adhoc.o datatest.o regt
> est.o fipsalgt.o dlltest.o ./libcryptopp.a  -lws2_32
> CreateProcess(c:\mingw\bin\g++.exe,g++ -o cryptest.exe -DNDEBUG -g2 -O2
> --std=c++11 -march=native -pipe test.o bench1.o bench2.o validat1.o
> validat2.o
>  validat3.o adhoc.o datatest.o regtest.o fipsalgt.o dlltest.o
> ./libcryptopp.a -lws2_32,...)
> Putting child 0x005ba968 (cryptest.exe) PID 6254928 on the chain.
> Live child 0x005ba968 (cryptesCannot create temporary file in
> C:\data\code\experimental\cryptopp565\c;\tmnp\: No such file or directory
> t
> This application has requested the Runtime to terminate it in an unusual
> way.
> Please contact the application's support team for more information.
> .exe) PID 6254928
> Reaping losing child 0x005ba968 PID 6254928
> make: *** [cryptest.exe] Error 3
> Removing child 0x005ba968 PID 6254928 from chain.

Hmm... Weird.

I'm not sure what to do with this one. It looks like MinGW is
providing malformed commands.

Has anyone come across it before?


> I did a git clone yesterday, and the 64-bit/64-bit compiler gives this
> error:
>   Must remake target `cryptlib.o'.
> g++ -DNDEBUG -g2 -O3 -wd68 -wd186 -wd279 -wd327 -wd161 -wd3180
> -DCRYPTOPP_DISABLE_ASM -pthread -KPIC -template=no%extdef -c cryptlib.cpp
> CreateProcess(c:\mingw\bin\g++.exe,g++ -DNDEBUG -g2 -O3 -wd68 -wd186 -wd279
> -wd327 -wd161 -wd3180 -DCRYPTOPP_DISABLE_ASM -pthread -KPIC -template=no%e
> xtdef -c cryptlib.cpp,...)
> Putting child 0x0219fa00 (cryptlib.o) PID 35177856 on the chain.
> Live child 0x0219fa00 (crg++: error: unrecognized command line option
> '-wd68'
> ypg++: error: unrecognized command line option '-wd186'
> tlg++: error: unrecognized command line option '-wd279'
> ibg++: error: unrecognized command line option '-wd327'
> .og++: error: unrecognized command line option '-wd161'
> ) PIg++: error: unrecognized command line option '-wd3180'
> D 3g++: error: unrecognized command line option '-KPIC'; did you mean
> '-fPIC'?
> 5177856

Ugh... That looks like a mashup of Intel ICC compiler warning
suppression (-wd186) and Sun CC pic option (-KPIC).

I think we are misidentifying the compiler. Could you provide the output of:

g++.exe -dumpmachine

And:

   g++.exe --version

Jeff

-- 
-- 
You received this message because you are subscribed to the "Crypto++ Users" 
Google Group.
To unsubscribe, send an email to cryptopp-users-unsubscr...@googlegroups.com.
More information about Crypto++ and this group is available at 
http://www.cryptopp.com.
--- 
You received this message because you are subscribed to the Google Groups 
"Crypto++ Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cryptopp-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: error: 'mutex' in namespace 'std' does not name a type

2017-11-07 Thread usbguru
Here are three more experiments building three different CryptoPP versions 
with the latest 64-bit/64-bit MingW compiler.

Since I already have a solution, this should have no sense of urgency.  Let 
me know if there is something specific I can do to help.

*I fixed my compiler version.  Now it is a 64-bit application and targeting 
64-bit:*

C:\data\code\experimental\cryptopp562>g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/x86_64-w64-mingw32/7.2.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../../../src/gcc-7.2.0/configure --host=x86_64-w64-mingw32 
--build=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --prefix=/mingw64 -
-with-sysroot=/c/mingw720/x86_64-720-posix-seh-rt_v5-rev0/mingw64 
--enable-shared --enable-static --disable-multilib 
--enable-languages=c,c++,fortran,
lto --enable-libstdcxx-time=yes --enable-threads=posix --enable-libgomp 
--enable-libatomic --enable-lto --enable-graphite --enable-checking=release 
--
enable-fully-dynamic-string --enable-version-specific-runtime-libs 
--enable-libstdcxx-filesystem-ts=yes --disable-libstdcxx-pch 
--disable-libstdcxx-de
bug --enable-bootstrap --disable-rpath --disable-win32-registry 
--disable-nls --disable-werror --disable-symvers --with-gnu-as 
--with-gnu-ld --with-ar
ch=nocona --with-tune=core2 --with-libiconv --with-system-zlib 
--with-gmp=/c/mingw720/prerequisites/x86_64-w64-mingw32-static 
--with-mpfr=/c/mingw720/
prerequisites/x86_64-w64-mingw32-static 
--with-mpc=/c/mingw720/prerequisites/x86_64-w64-mingw32-static 
--with-isl=/c/mingw720/prerequisites/x86_64-w64
-mingw32-static --with-pkgversion='x86_64-posix-seh-rev0, Built by 
MinGW-W64 project' --with-bugurl=https://sourceforge.net/projects/mingw-w64 
CFLAGS=
'-O2 -pipe -fno-ident 
-I/c/mingw720/x86_64-720-posix-seh-rt_v5-rev0/mingw64/opt/include 
-I/c/mingw720/prerequisites/x86_64-zlib-static/include -I/c/mi
ngw720/prerequisites/x86_64-w64-mingw32-static/include' CXXFLAGS='-O2 -pipe 
-fno-ident -I/c/mingw720/x86_64-720-posix-seh-rt_v5-rev0/mingw64/opt/inclu
de -I/c/mingw720/prerequisites/x86_64-zlib-static/include 
-I/c/mingw720/prerequisites/x86_64-w64-mingw32-static/include' CPPFLAGS=' 
-I/c/mingw720/x86_
64-720-posix-seh-rt_v5-rev0/mingw64/opt/include 
-I/c/mingw720/prerequisites/x86_64-zlib-static/include 
-I/c/mingw720/prerequisites/x86_64-w64-mingw32-
static/include' LDFLAGS='-pipe -fno-ident 
-L/c/mingw720/x86_64-720-posix-seh-rt_v5-rev0/mingw64/opt/lib 
-L/c/mingw720/prerequisites/x86_64-zlib-static
/lib -L/c/mingw720/prerequisites/x86_64-w64-mingw32-static/lib '
Thread model: posix
gcc version 7.2.0 (x86_64-posix-seh-rev0, Built by MinGW-W64 project)

*COMPILING CRYPTOPP562 has this error:*
g++ -DNDEBUG -g -O2 -march=native -DCRYPTOPP_DISABLE_ASM -pipe -c wake.cpp
wake.cpp: In member function 'void 
CryptoPP::WAKE_Base::GenKey(CryptoPP::word32, CryptoPP::word32, 
CryptoPP::word32, CryptoPP::word32)':
wake.cpp:34:15: error: narrowing conversion of '3868867420' from 'unsigned 
int' to 'int' inside { } [-Wnarrowing]
   0x9ee27cf3, } ;
   ^
wake.cpp:34:15: error: narrowing conversion of '3553042405' from 'unsigned 
int' to 'int' inside { } [-Wnarrowing]
wake.cpp:34:15: error: narrowing conversion of '2872865746' from 'unsigned 
int' to 'int' inside { } [-Wnarrowing]
wake.cpp:34:15: error: narrowing conversion of '2665643251' from 'unsigned 
int' to 'int' inside { } [-Wnarrowing]
make: *** [wake.o] Error 1


*COMPILING CRYPTOPP565 gives a weird error and pops up a crash dialog:*
g++ -o cryptest.exe -DNDEBUG -g2 -O2 --std=c++11 -march=native -pipe test.o 
bench1.o bench2.o validat1.o validat2.o validat3.o adhoc.o datatest.o regt
est.o fipsalgt.o dlltest.o ./libcryptopp.a  -lws2_32
CreateProcess(c:\mingw\bin\g++.exe,g++ -o cryptest.exe -DNDEBUG -g2 -O2 
--std=c++11 -march=native -pipe test.o bench1.o bench2.o validat1.o 
validat2.o
 validat3.o adhoc.o datatest.o regtest.o fipsalgt.o dlltest.o 
./libcryptopp.a -lws2_32,...)
Putting child 0x005ba968 (cryptest.exe) PID 6254928 on the chain.
Live child 0x005ba968 (cryptesCannot create temporary file in 
C:\data\code\experimental\cryptopp565\c;\tmnp\: No such file or directory
t
This application has requested the Runtime to terminate it in an unusual 
way.
Please contact the application's support team for more information.
.exe) PID 6254928
Reaping losing child 0x005ba968 PID 6254928
make: *** [cryptest.exe] Error 3
Removing child 0x005ba968 PID 6254928 from chain.

*I did a git clone yesterday, and the 64-bit/64-bit compiler gives this 
error:*
  Must remake target `cryptlib.o'.
g++ -DNDEBUG -g2 -O3 -wd68 -wd186 -wd279 -wd327 -wd161 -wd3180 
-DCRYPTOPP_DISABLE_ASM -pthread -KPIC -template=no%extdef -c cryptlib.cpp
CreateProcess(c:\mingw\bin\g++.exe,g++ -DNDEBUG -g2 -O3 -wd68 -wd186 -wd279 
-wd327 -wd161 -wd3180 -DCRYPTOPP_DISABLE_ASM -pthread -KPIC -template=no%e
xtdef -c cryptlib.cpp,...)
Putting child 0x0219fa00 (cryptlib.o) PID 35177856 on the chain.
Live 

Re: error: 'mutex' in namespace 'std' does not name a type

2017-11-06 Thread Marcel Raad
Hi Jeff,

Am 06.11.2017 20:20 schrieb "Jeffrey Walton" :

How does this fancy you:

$ git diff
diff --git a/socketft.cpp b/socketft.cpp
index 454eaa5..20cda22 100644
--- a/socketft.cpp
+++ b/socketft.cpp
@@ -30,6 +30,14 @@
 # include 
 #endif

+// From http://groups.google.com/d/msg/cryptopp-users/
MzvocLrbIpE/TMCa6LFhCgAJ,
+//  is a compatibility header and it needs _WIN32_WINNT >=
0x501.
+// The work-around should be OK since it won't cross-pollinate into header
files.
+#if defined(__MINGW32__) && (_WIN32_WINNT < 0x501)
+# undef _WIN32_WINNT
+# define _WIN32_WINNT 0x501
+#endif


sorry, I hadn't seen your e-mail until now and have created a pull request
with another option, defining it in the makefile if the user didn't
explicitly specify the target Windows version. Defining it only in
socketft.cpp would be good too, of course.

Note that MinGW-w64 also defines __MINGW32__ and doesn't target Windows
2000 by default. But I think it targets Windows XP anyway by default, so it
would make no difference.

Marcel

-- 
-- 
You received this message because you are subscribed to the "Crypto++ Users" 
Google Group.
To unsubscribe, send an email to cryptopp-users-unsubscr...@googlegroups.com.
More information about Crypto++ and this group is available at 
http://www.cryptopp.com.
--- 
You received this message because you are subscribed to the Google Groups 
"Crypto++ Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cryptopp-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: error: 'mutex' in namespace 'std' does not name a type

2017-11-06 Thread Jeffrey Walton


On Monday, November 6, 2017 at 1:36:36 PM UTC-5, Marcel Raad wrote:
>
> Hi Jeff,
>
> Am 06.11.2017 19:29 schrieb "Jeffrey Walton" :
>
> Should we remove that header or comment it out? I don't know anyone
> developing on Windows 2000 anymore. Windows XP and Windows 2003 are
> the floors for the development shops I work with.
>
>
> unfortunately that wouldn't help either as then the needed functions would 
> not be available. MinGW should really set their default Windows version to 
> something more current. As nothing needing later Windows versions is used 
> at all in Crypto++, I wouldn't actively remove it.
>

Ack, thanks.

How does this fancy you:

$ git diff
diff --git a/socketft.cpp b/socketft.cpp
index 454eaa5..20cda22 100644
--- a/socketft.cpp
+++ b/socketft.cpp
@@ -30,6 +30,14 @@
 # include 
 #endif

+// From 
http://groups.google.com/d/msg/cryptopp-users/MzvocLrbIpE/TMCa6LFhCgAJ,
+//  is a compatibility header and it needs _WIN32_WINNT >= 
0x501.
+// The work-around should be OK since it won't cross-pollinate into header 
files.
+#if defined(__MINGW32__) && (_WIN32_WINNT < 0x501)
+# undef _WIN32_WINNT
+# define _WIN32_WINNT 0x501
+#endif

I think we need to put up a wiki page on this: 
https://www.cryptopp.com/wiki/MinGW_(Command_Line). Folks should not be 
having this much trouble. In the absence of "it just works" we should 
provide a canonical source of solutions.

Jeff

-- 
-- 
You received this message because you are subscribed to the "Crypto++ Users" 
Google Group.
To unsubscribe, send an email to cryptopp-users-unsubscr...@googlegroups.com.
More information about Crypto++ and this group is available at 
http://www.cryptopp.com.
--- 
You received this message because you are subscribed to the Google Groups 
"Crypto++ Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cryptopp-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: error: 'mutex' in namespace 'std' does not name a type

2017-11-06 Thread Marcel Raad
Hi Jeff,

Am 06.11.2017 19:29 schrieb "Jeffrey Walton" :

Should we remove that header or comment it out? I don't know anyone
developing on Windows 2000 anymore. Windows XP and Windows 2003 are
the floors for the development shops I work with.


unfortunately that wouldn't help either as then the needed functions would
not be available. MinGW should really set their default Windows version to
something more current. As nothing needing later Windows versions is used
at all in Crypto++, I wouldn't actively remove it.

Marcel

-- 
-- 
You received this message because you are subscribed to the "Crypto++ Users" 
Google Group.
To unsubscribe, send an email to cryptopp-users-unsubscr...@googlegroups.com.
More information about Crypto++ and this group is available at 
http://www.cryptopp.com.
--- 
You received this message because you are subscribed to the Google Groups 
"Crypto++ Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cryptopp-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: error: 'mutex' in namespace 'std' does not name a type

2017-11-06 Thread Jeffrey Walton
On Mon, Nov 6, 2017 at 1:20 PM, Marcel Raad  wrote:
>
> Am 06.11.2017 18:55 schrieb :
>
> g++ -DNDEBUG -g2 -O3 -pthread -pipe -c socketft.cpp
> socketft.cpp:36:23: fatal error: wspiapi.h: No such file or directory
>  #  include 
>^
> compilation terminated.
> make: *** [socketft.o] Error 1
>
> you can define _WIN32_WINNT to at least 0x501 to avoid that. This is a
> compatibility header needed if you target Windows 2000. Unfortunately
> mingw.org MinGW targets Windows 2000 by default AND doesn't provide this
> header.
>
> But using MinGW-w64 would be less painful, I think - preferably the pthreads
> variant to also avoid the mutex error.

Thanks Marcel.

Should we remove that header or comment it out? I don't know anyone
developing on Windows 2000 anymore. Windows XP and Windows 2003 are
the floors for the development shops I work with.

I'm wondering if should document the  gyrations somewhere.
I don't recall it being in our README or INSTALL, and a quick grep
shows 0 hits.

Related, someone was recently saying they fetched the header from a
GitHub, but I can't find the message at the moment. Maybe one of
these: https://www.google.com/search?q="wspiapi.h"+site:github.com .

Jeff

-- 
-- 
You received this message because you are subscribed to the "Crypto++ Users" 
Google Group.
To unsubscribe, send an email to cryptopp-users-unsubscr...@googlegroups.com.
More information about Crypto++ and this group is available at 
http://www.cryptopp.com.
--- 
You received this message because you are subscribed to the Google Groups 
"Crypto++ Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cryptopp-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: error: 'mutex' in namespace 'std' does not name a type

2017-11-06 Thread Marcel Raad
Hi Gene,

Am 06.11.2017 18:55 schrieb :

g++ -DNDEBUG -g2 -O3 -pthread -pipe -c socketft.cpp
socketft.cpp:36:23: fatal error: wspiapi.h: No such file or directory
 #  include 
   ^
compilation terminated.
make: *** [socketft.o] Error 1


you can define _WIN32_WINNT to at least 0x501 to avoid that. This is a
compatibility header needed if you target Windows 2000. Unfortunately
mingw.org MinGW targets Windows 2000 by default AND doesn't provide this
header.

But using MinGW-w64 would be less painful, I think - preferably the
pthreads variant to also avoid the mutex error.

Marcel

-- 
-- 
You received this message because you are subscribed to the "Crypto++ Users" 
Google Group.
To unsubscribe, send an email to cryptopp-users-unsubscr...@googlegroups.com.
More information about Crypto++ and this group is available at 
http://www.cryptopp.com.
--- 
You received this message because you are subscribed to the Google Groups 
"Crypto++ Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cryptopp-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: error: 'mutex' in namespace 'std' does not name a type

2017-11-06 Thread usbguru
Thanks for checking my Win32/Win64 hybrid.  I had no idea I was doing that.

I did try your latest version, and got pretty far with my setup:
g++ -DNDEBUG -g2 -O3 -pthread -pipe -c rsa.cpp
In file included from filters.h:22:0,
 from pubkey.h:48,
 from rsa.h:12,
 from rsa.cpp:4:
algparam.h: In destructor 'virtual 
CryptoPP::AlgorithmParametersBase::~AlgorithmParametersBase()':
algparam.h:333:34: warning: throw will always call terminate() [-Wterminate]
 throw ParameterNotUsed(m_name);
  ^
algparam.h:333:34: note: in C++11 destructors default to noexcept
g++ -DNDEBUG -g2 -O3 -pthread -pipe -c rw.cpp
In file included from filters.h:22:0,
 from pubkey.h:48,
 from rw.h:15,
 from rw.cpp:5:
algparam.h: In destructor 'virtual 
CryptoPP::AlgorithmParametersBase::~AlgorithmParametersBase()':
algparam.h:333:34: warning: throw will always call terminate() [-Wterminate]
 throw ParameterNotUsed(m_name);
  ^
algparam.h:333:34: note: in C++11 destructors default to noexcept
g++ -DNDEBUG -g2 -O3 -pthread -pipe -c safer.cpp
g++ -DNDEBUG -g2 -O3 -pthread -pipe -c salsa.cpp
g++ -DNDEBUG -g2 -O3 -pthread -pipe -c seal.cpp
g++ -DNDEBUG -g2 -O3 -pthread -pipe -c seed.cpp
g++ -DNDEBUG -g2 -O3 -pthread -pipe -c serpent.cpp
g++ -DNDEBUG -g2 -O3 -pthread -pipe -msse4.2 -msha -c sha-simd.cpp
g++ -DNDEBUG -g2 -O3 -pthread -pipe -c sha.cpp
g++ -DNDEBUG -g2 -O3 -pthread -pipe -c sha3.cpp
g++ -DNDEBUG -g2 -O3 -pthread -pipe -msse4.2 -msha -c shacal2-simd.cpp
g++ -DNDEBUG -g2 -O3 -pthread -pipe -c shacal2.cpp
g++ -DNDEBUG -g2 -O3 -pthread -pipe -c shark.cpp
In file included from modes.h:14:0,
 from shark.cpp:6:
algparam.h: In destructor 'virtual 
CryptoPP::AlgorithmParametersBase::~AlgorithmParametersBase()':
algparam.h:333:34: warning: throw will always call terminate() [-Wterminate]
 throw ParameterNotUsed(m_name);
  ^
algparam.h:333:34: note: in C++11 destructors default to noexcept
g++ -DNDEBUG -g2 -O3 -pthread -pipe -c sharkbox.cpp
g++ -DNDEBUG -g2 -O3 -pthread -pipe -c skipjack.cpp
g++ -DNDEBUG -g2 -O3 -pthread -pipe -c socketft.cpp
socketft.cpp:36:23: fatal error: wspiapi.h: No such file or directory
 #  include 
   ^
compilation terminated.
make: *** [socketft.o] Error 1

I will check out my MingW options.

Thanks,

Gene

On Monday, November 6, 2017 at 7:22:26 AM UTC-8, Jeffrey Walton wrote:
>
> On Mon, Nov 6, 2017 at 9:28 AM,   wrote: 
> > Here are the details on the two MingW compilers I used, with 630 first: 
> > 
> > C:\data\code>g++ -v 
> > Using built-in specs. 
> > COLLECT_GCC=g++ 
> > 
> COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/6.3.0/lto-wrapper.exe 
>
> > Target: mingw32 
> > Configured with: ../src/gcc-6.3.0/configure --build=x86_64-pc-linux-gnu 
> > --host=mingw32 --with-gmp=/mingw --with-mpfr=/mingw --with-mpc=/mingw 
> > --with-i 
> > sl=/mingw --prefix=/mingw --disable-win32-registry --target=mingw32 
> > --with-arch=i586 --enable-languages=c,c++,objc,obj-c++,fortran,ada 
> > --with-pkgversi 
> > on='MinGW.org GCC-6.3.0-1' --enable-static --enable-shared 
> --enable-threads 
> > --with-dwarf2 --disable-sjlj-exceptions 
> --enable-version-specific-runtime- 
> > libs --with-libiconv-prefix=/mingw --with-libintl-prefix=/mingw 
> > --enable-libstdcxx-debug --with-tune=generic --enable-libgomp 
> > --disable-libvtv --enabl 
> > e-nls 
> > Thread model: win32 
> > gcc version 6.3.0 (MinGW.org GCC-6.3.0-1) 
>
> Looking at "--build=x86_64-pc-linux-gnu --host=mingw32", I can't help 
> but laugh... It looks like you are using a 32-bit MinGW to 
> cross-compile for x86_64. You are a glutton for punishment :) 
>
> My guess is that you are hitting problem 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 possible provide C++11 because the underlying platform 
> cannot. 
>
> I think your best bet at this point is to 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 (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) || 
> 

Re: error: 'mutex' in namespace 'std' does not name a type

2017-11-06 Thread Jeffrey Walton
On Mon, Nov 6, 2017 at 9:28 AM,   wrote:
> Here are the details on the two MingW compilers I used, with 630 first:
>
> C:\data\code>g++ -v
> Using built-in specs.
> COLLECT_GCC=g++
> COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/6.3.0/lto-wrapper.exe
> Target: mingw32
> Configured with: ../src/gcc-6.3.0/configure --build=x86_64-pc-linux-gnu
> --host=mingw32 --with-gmp=/mingw --with-mpfr=/mingw --with-mpc=/mingw
> --with-i
> sl=/mingw --prefix=/mingw --disable-win32-registry --target=mingw32
> --with-arch=i586 --enable-languages=c,c++,objc,obj-c++,fortran,ada
> --with-pkgversi
> on='MinGW.org GCC-6.3.0-1' --enable-static --enable-shared --enable-threads
> --with-dwarf2 --disable-sjlj-exceptions --enable-version-specific-runtime-
> libs --with-libiconv-prefix=/mingw --with-libintl-prefix=/mingw
> --enable-libstdcxx-debug --with-tune=generic --enable-libgomp
> --disable-libvtv --enabl
> e-nls
> Thread model: win32
> gcc version 6.3.0 (MinGW.org GCC-6.3.0-1)

Looking at "--build=x86_64-pc-linux-gnu --host=mingw32", I can't help
but laugh... It looks like you are using a 32-bit MinGW to
cross-compile for x86_64. You are a glutton for punishment :)

My guess is that you are hitting problem 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 possible provide C++11 because the underlying platform
cannot.

I think your best bet at this point is to 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 (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 >= 4) || \
(__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.

Jeff

-- 
-- 
You received this message because you are subscribed to the "Crypto++ Users" 
Google Group.
To unsubscribe, send an email to cryptopp-users-unsubscr...@googlegroups.com.
More information about Crypto++ and this group is available at 
http://www.cryptopp.com.
--- 
You received this message because you are subscribed to the Google Groups 
"Crypto++ Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cryptopp-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: error: 'mutex' in namespace 'std' does not name a type

2017-11-06 Thread usbguru
Hi Jeff,
Here are the details on the two MingW compilers I used, with 630 first:

C:\data\code>g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/6.3.0/lto-wrapper.exe
Target: mingw32
Configured with: ../src/gcc-6.3.0/configure --build=x86_64-pc-linux-gnu 
--host=mingw32 --with-gmp=/mingw --with-mpfr=/mingw --with-mpc=/mingw 
--with-i
sl=/mingw --prefix=/mingw --disable-win32-registry --target=mingw32 
--with-arch=i586 --enable-languages=c,c++,objc,obj-c++,fortran,ada 
--with-pkgversi
on='MinGW.org GCC-6.3.0-1' --enable-static --enable-shared --enable-threads 
--with-dwarf2 --disable-sjlj-exceptions --enable-version-specific-runtime-
libs --with-libiconv-prefix=/mingw --with-libintl-prefix=/mingw 
--enable-libstdcxx-debug --with-tune=generic --enable-libgomp 
--disable-libvtv --enabl
e-nls
Thread model: win32
gcc version 6.3.0 (MinGW.org GCC-6.3.0-1)

C:\data\code>\mingw472\bin\g++ -v
Using built-in specs.
COLLECT_GCC=\mingw472\bin\g++
COLLECT_LTO_WRAPPER=c:/mingw472/bin/../libexec/gcc/mingw32/4.7.2/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.7.2/configure 
--enable-languages=c,c++,ada,fortran,objc,obj-c++ --disable-sjlj-exceptions 
--with-dwarf2 --enable-shared --en
able-libgomp --disable-win32-registry --enable-libstdcxx-debug 
--disable-build-poststage1-with-cxx --enable-version-specific-runtime-libs 
--build=ming
w32 --prefix=/mingw
Thread model: win32
gcc version 4.7.2 (GCC)

I will try your latest and let you know how that goes.

Thanks,

Gene

On Monday, November 6, 2017 at 6:20:52 AM UTC-8, Jeffrey Walton wrote:
>
>
>
> On Saturday, November 4, 2017 at 3:45:32 PM UTC-4, usb...@gmail.com 
>  wrote:
>>
>> I got it fixed... kind of.
>>
>> On a hunch, I switched back to MinGW4.72, and CryptoPP565 still failed to 
>> build.   After trying all permutations of my setups, here is what I found:
>>
>> MinGW CryptoPP
>> 630   565fail
>> 630   562fail
>> 472   565fail
>> 472   562works fine
>>
>> Going back to my old MinGW and old CryptoPP worked fine.  I only switched 
>> MinGW because the old one no longer works with Boost.  Unfortunately, 630 
>> does not work for Boost either :-)
>>
>> I will keep monitoring the CryptoPP site and this group and test new 
>> releases when they are available.
>>
>
> I think we may have mostly cleared it at 
> https://github.com/weidai11/cryptopp/commit/e4cef84883b2.
>
> You should perform a `git pull`, and then uncomment the define for 
> CRYPTOPP_NO_CXX11 in config.h around line 65:
>
> // 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
>
> Jeff
>

-- 
-- 
You received this message because you are subscribed to the "Crypto++ Users" 
Google Group.
To unsubscribe, send an email to cryptopp-users-unsubscr...@googlegroups.com.
More information about Crypto++ and this group is available at 
http://www.cryptopp.com.
--- 
You received this message because you are subscribed to the Google Groups 
"Crypto++ Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cryptopp-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: error: 'mutex' in namespace 'std' does not name a type

2017-11-06 Thread Jeffrey Walton


On Saturday, November 4, 2017 at 3:45:32 PM UTC-4, usbg...@gmail.com wrote:
>
> I got it fixed... kind of.
>
> On a hunch, I switched back to MinGW4.72, and CryptoPP565 still failed to 
> build.   After trying all permutations of my setups, here is what I found:
>
> MinGW CryptoPP
> 630   565fail
> 630   562fail
> 472   565fail
> 472   562works fine
>
> Going back to my old MinGW and old CryptoPP worked fine.  I only switched 
> MinGW because the old one no longer works with Boost.  Unfortunately, 630 
> does not work for Boost either :-)
>
> I will keep monitoring the CryptoPP site and this group and test new 
> releases when they are available.
>

I think we may have mostly cleared it at 
https://github.com/weidai11/cryptopp/commit/e4cef84883b2.

You should perform a `git pull`, and then uncomment the define for 
CRYPTOPP_NO_CXX11 in config.h around line 65:

// 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

Jeff

-- 
-- 
You received this message because you are subscribed to the "Crypto++ Users" 
Google Group.
To unsubscribe, send an email to cryptopp-users-unsubscr...@googlegroups.com.
More information about Crypto++ and this group is available at 
http://www.cryptopp.com.
--- 
You received this message because you are subscribed to the Google Groups 
"Crypto++ Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cryptopp-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: error: 'mutex' in namespace 'std' does not name a type

2017-11-06 Thread Jeffrey Walton


On Sunday, November 5, 2017 at 5:08:08 PM UTC-5, Marcel Raad wrote:
>
> On Saturday, November 4, 2017 at 10:36:30 PM UTC+1, Jeffrey Walton wrote:
> > I tired to setup a MinGW testing environment several times but it either 
> (1) never worked or (2) broke immediately. On the rare occasions I could 
> compile and link I was able to file some MinGW bug reports but they were 
> never acknowledged.
> > 
> > I'm happy to try to support it, but we can't do it without folks testing 
> and filing the bug reports. Without the testers and the bug reports things 
> will likely stay broken.
>
> I'll try testing MinGW again in the coming days. I was very busy in the 
> last few weeks, but that should get better now.
>
> Gene, what MinGW flavor are you using? The original 32-bit-only one from 
> mingw.org?
>
> The problem is that there's no threading support in libstdc++ when using 
> native Windows threads. Compilation works fine for me with the pthreads 
> version of MinGW-w64. It should also be possible to use a third-party 
> pthreads library with the original mingw.org MinGW as mentioned here [1], 
> but I've never tried that yet.
>
> Hopefully it's also possible to distinguish between threading libraries 
> used at compile time and set CRYPTOPP_CXX11_SYNCHRONIZATION accordingly. 
> I'll look into that soon.
>

Something else just occurred to me...  Add `-std=c++03` should clear the 
issue by avoiding the C++11 gear.

Jeff

-- 
-- 
You received this message because you are subscribed to the "Crypto++ Users" 
Google Group.
To unsubscribe, send an email to cryptopp-users-unsubscr...@googlegroups.com.
More information about Crypto++ and this group is available at 
http://www.cryptopp.com.
--- 
You received this message because you are subscribed to the Google Groups 
"Crypto++ Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cryptopp-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: error: 'mutex' in namespace 'std' does not name a type

2017-11-06 Thread Jeffrey Walton


On Monday, November 6, 2017 at 7:23:41 AM UTC-5, Jeffrey Walton wrote:
>
>
>
> On Sunday, November 5, 2017 at 5:08:08 PM UTC-5, Marcel Raad wrote:
>>
>> On Saturday, November 4, 2017 at 10:36:30 PM UTC+1, Jeffrey Walton wrote:
>> > I tired to setup a MinGW testing environment several times but it 
>> either (1) never worked or (2) broke immediately. On the rare occasions I 
>> could compile and link I was able to file some MinGW bug reports but they 
>> were never acknowledged.
>> > 
>> > I'm happy to try to support it, but we can't do it without folks 
>> testing and filing the bug reports. Without the testers and the bug reports 
>> things will likely stay broken.
>>
>> I'll try testing MinGW again in the coming days. I was very busy in the 
>> last few weeks, but that should get better now.
>>
>> Gene, what MinGW flavor are you using? The original 32-bit-only one from 
>> mingw.org?
>>
>> The problem is that there's no threading support in libstdc++ when using 
>> native Windows threads. Compilation works fine for me with the pthreads 
>> version of MinGW-w64. It should also be possible to use a third-party 
>> pthreads library with the original mingw.org MinGW as mentioned here 
>> [1], but I've never tried that yet.
>>
>> Hopefully it's also possible to distinguish between threading libraries 
>> used at compile time and set CRYPTOPP_CXX11_SYNCHRONIZATION accordingly. 
>> I'll look into that soon.
>>
>> [1] http://www.mingw.org/wiki/pthreads_library
>>
>
> Thanks for that Marcel.
>
> Your comment got me out of the fishbowl. The bigger engineering problem 
> is, we don't offer a way to easily disable C++11 when a compiler and header 
> files claim to support it.
>
> Now open in the bug tracker: "Add CRYPTOPP_NO_CXX11 for old compilers" 
> (). I'm testing CRYPTOPP_NO_CXX11 now, and it should be checked-in shortly.
>

Ugh Here's the URL: https://github.com/weidai11/cryptopp/issues/529.

Jeff

-- 
-- 
You received this message because you are subscribed to the "Crypto++ Users" 
Google Group.
To unsubscribe, send an email to cryptopp-users-unsubscr...@googlegroups.com.
More information about Crypto++ and this group is available at 
http://www.cryptopp.com.
--- 
You received this message because you are subscribed to the Google Groups 
"Crypto++ Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cryptopp-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: error: 'mutex' in namespace 'std' does not name a type

2017-11-06 Thread Jeffrey Walton


On Sunday, November 5, 2017 at 5:08:08 PM UTC-5, Marcel Raad wrote:
>
> On Saturday, November 4, 2017 at 10:36:30 PM UTC+1, Jeffrey Walton wrote:
> > I tired to setup a MinGW testing environment several times but it either 
> (1) never worked or (2) broke immediately. On the rare occasions I could 
> compile and link I was able to file some MinGW bug reports but they were 
> never acknowledged.
> > 
> > I'm happy to try to support it, but we can't do it without folks testing 
> and filing the bug reports. Without the testers and the bug reports things 
> will likely stay broken.
>
> I'll try testing MinGW again in the coming days. I was very busy in the 
> last few weeks, but that should get better now.
>
> Gene, what MinGW flavor are you using? The original 32-bit-only one from 
> mingw.org?
>
> The problem is that there's no threading support in libstdc++ when using 
> native Windows threads. Compilation works fine for me with the pthreads 
> version of MinGW-w64. It should also be possible to use a third-party 
> pthreads library with the original mingw.org MinGW as mentioned here [1], 
> but I've never tried that yet.
>
> Hopefully it's also possible to distinguish between threading libraries 
> used at compile time and set CRYPTOPP_CXX11_SYNCHRONIZATION accordingly. 
> I'll look into that soon.
>
> [1] http://www.mingw.org/wiki/pthreads_library
>

Thanks for that Marcel.

Your comment got me out of the fishbowl. The bigger engineering problem is, 
we don't offer a way to easily disable C++11 when a compiler and header 
files claim to support it.

Now open in the bug tracker: "Add CRYPTOPP_NO_CXX11 for old compilers" (). 
I'm testing CRYPTOPP_NO_CXX11 now, and it should be checked-in shortly.

Jeff

-- 
-- 
You received this message because you are subscribed to the "Crypto++ Users" 
Google Group.
To unsubscribe, send an email to cryptopp-users-unsubscr...@googlegroups.com.
More information about Crypto++ and this group is available at 
http://www.cryptopp.com.
--- 
You received this message because you are subscribed to the Google Groups 
"Crypto++ Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cryptopp-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: error: 'mutex' in namespace 'std' does not name a type

2017-11-05 Thread Marcel Raad
On Saturday, November 4, 2017 at 10:36:30 PM UTC+1, Jeffrey Walton wrote:
> I tired to setup a MinGW testing environment several times but it either (1) 
> never worked or (2) broke immediately. On the rare occasions I could compile 
> and link I was able to file some MinGW bug reports but they were never 
> acknowledged.
> 
> 
> 
> I'm happy to try to support it, but we can't do it without folks testing and 
> filing the bug reports. Without the testers and the bug reports things will 
> likely stay broken.

I'll try testing MinGW again in the coming days. I was very busy in the last 
few weeks, but that should get better now.

Gene, what MinGW flavor are you using? The original 32-bit-only one from 
mingw.org?

The problem is that there's no threading support in libstdc++ when using native 
Windows threads. Compilation works fine for me with the pthreads version of 
MinGW-w64. It should also be possible to use a third-party pthreads library 
with the original mingw.org MinGW as mentioned here [1], but I've never tried 
that yet.

Hopefully it's also possible to distinguish between threading libraries used at 
compile time and set CRYPTOPP_CXX11_SYNCHRONIZATION accordingly. I'll look into 
that soon.

[1] http://www.mingw.org/wiki/pthreads_library

Marcel

-- 
-- 
You received this message because you are subscribed to the "Crypto++ Users" 
Google Group.
To unsubscribe, send an email to cryptopp-users-unsubscr...@googlegroups.com.
More information about Crypto++ and this group is available at 
http://www.cryptopp.com.
--- 
You received this message because you are subscribed to the Google Groups 
"Crypto++ Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cryptopp-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: error: 'mutex' in namespace 'std' does not name a type

2017-11-04 Thread Jeffrey Walton


On Saturday, November 4, 2017 at 3:45:32 PM UTC-4, usbg...@gmail.com wrote:
>
> I got it fixed... kind of.
>
> On a hunch, I switched back to MinGW4.72, and CryptoPP565 still failed to 
> build.   After trying all permutations of my setups, here is what I found:
>
> MinGW CryptoPP
> 630   565fail
> 630   562fail
> 472   565fail
> 472   562works fine
>
> Going back to my old MinGW and old CryptoPP worked fine.  I only switched 
> MinGW because the old one no longer works with Boost.  Unfortunately, 630 
> does not work for Boost either :-)
>
> I will keep monitoring the CryptoPP site and this group and test new 
> releases when they are available.
>

Yeah, the problem for the project is, MinGW was abandoned back in 2008 or 
so and we don't have MinGW testers.

I tired to setup a MinGW testing environment several times but it either 
(1) never worked or (2) broke immediately. On the rare occasions I could 
compile and link I was able to file some MinGW bug reports but they were 
never acknowledged.

I'm happy to try to support it, but we can't do it without folks testing 
and filing the bug reports. Without the testers and the bug reports things 
will likely stay broken.

Jeff

-- 
-- 
You received this message because you are subscribed to the "Crypto++ Users" 
Google Group.
To unsubscribe, send an email to cryptopp-users-unsubscr...@googlegroups.com.
More information about Crypto++ and this group is available at 
http://www.cryptopp.com.
--- 
You received this message because you are subscribed to the Google Groups 
"Crypto++ Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cryptopp-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: error: 'mutex' in namespace 'std' does not name a type

2017-11-04 Thread usbguru
I got it fixed... kind of.

On a hunch, I switched back to MinGW4.72, and CryptoPP565 still failed to 
build.   After trying all permutations of my setups, here is what I found:

MinGW CryptoPP
630   565fail
630   562fail
472   565fail
472   562works fine

Going back to my old MinGW and old CryptoPP worked fine.  I only switched 
MinGW because the old one no longer works with Boost.  Unfortunately, 630 
does not work for Boost either :-)

I will keep monitoring the CryptoPP site and this group and test new 
releases when they are available.

Thanks,

Gene

On Saturday, November 4, 2017 at 11:52:55 AM UTC-7, usb...@gmail.com wrote:
>
> Hi Jeff,
> thanks for your reply.  I have never used git, so it took some time to 
> decipher the patch format.  I applied it manually to my config.h file, but 
> got more errors, not less.
>
> Could you post a complete config.h file?  I hope that is enough to fix 
> this.
>
> Thanks,
>
> Gene
>
> On Friday, November 3, 2017 at 3:20:46 PM UTC-7, Jeffrey Walton wrote:
>>
>>
>>
>> On Friday, November 3, 2017 at 6:09:20 PM UTC-4, usb...@gmail.com wrote:
>>>
>>> I am building CryptoPP 5.65 with MingW 6.3.0.
>>>
>>> make gives  an error:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *c:\devdir\>makeg++ -DNDEBUG -g2 -O2 -march=native -pipe -c 
>>> cryptlib.cppIn file included from cryptlib.cpp:19:0:misc.h: In member 
>>> function 'const T& CryptoPP::Singleton::Ref() 
>>> const':misc.h:287:14: error: 'mutex' in namespace 'std' does not name a 
>>> type  static std::mutex s_mutex;  ^misc.h:296:18: error: 
>>> 'mutex' is not a member of 'std'  std::lock_guard 
>>> lock(s_mutex);  ^~~misc.h:296:18: error: 'mutex' is not a 
>>> member of 'std'misc.h:296:28: error: template argument 1 is invalid  
>>> std::lock_guard lock(s_mutex);
>>> ^misc.h:296:35: error: 's_mutex' was not declared in this scope  
>>> std::lock_guard 
>>> lock(s_mutex);   ^~~make: *** 
>>> [cryptlib.o] Error 1*
>>> I ran   *make -d*   and can post that if anyone thinks that will help.
>>>
>>> What do I do to fix this?
>>>
>>
>> If you are working on Master, then try this change: "Crypto++ MinGW 
>> std::mutex patch", https://pastebin.com/FqLPUj0H. The patch may not 
>> apply cleanly because I am on my testing branch, but the same change 
>> applies to Master.
>>
>> A Crypto++ 5.6.5 change should be similar. But you should consider 
>> working from Master because it has two CVE bug fixes and it is mostly 
>> stable.
>>
>> Jeff
>>
>

-- 
-- 
You received this message because you are subscribed to the "Crypto++ Users" 
Google Group.
To unsubscribe, send an email to cryptopp-users-unsubscr...@googlegroups.com.
More information about Crypto++ and this group is available at 
http://www.cryptopp.com.
--- 
You received this message because you are subscribed to the Google Groups 
"Crypto++ Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cryptopp-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: error: 'mutex' in namespace 'std' does not name a type

2017-11-04 Thread usbguru
Hi Jeff,
thanks for your reply.  I have never used git, so it took some time to 
decipher the patch format.  I applied it manually to my config.h file, but 
got more errors, not less.

Could you post a complete config.h file?  I hope that is enough to fix this.

Thanks,

Gene

On Friday, November 3, 2017 at 3:20:46 PM UTC-7, Jeffrey Walton wrote:
>
>
>
> On Friday, November 3, 2017 at 6:09:20 PM UTC-4, usb...@gmail.com 
>  wrote:
>>
>> I am building CryptoPP 5.65 with MingW 6.3.0.
>>
>> make gives  an error:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *c:\devdir\>makeg++ -DNDEBUG -g2 -O2 -march=native -pipe -c 
>> cryptlib.cppIn file included from cryptlib.cpp:19:0:misc.h: In member 
>> function 'const T& CryptoPP::Singleton::Ref() 
>> const':misc.h:287:14: error: 'mutex' in namespace 'std' does not name a 
>> type  static std::mutex s_mutex;  ^misc.h:296:18: error: 
>> 'mutex' is not a member of 'std'  std::lock_guard 
>> lock(s_mutex);  ^~~misc.h:296:18: error: 'mutex' is not a 
>> member of 'std'misc.h:296:28: error: template argument 1 is invalid  
>> std::lock_guard lock(s_mutex);
>> ^misc.h:296:35: error: 's_mutex' was not declared in this scope  
>> std::lock_guard 
>> lock(s_mutex);   ^~~make: *** 
>> [cryptlib.o] Error 1*
>> I ran   *make -d*   and can post that if anyone thinks that will help.
>>
>> What do I do to fix this?
>>
>
> If you are working on Master, then try this change: "Crypto++ MinGW 
> std::mutex patch", https://pastebin.com/FqLPUj0H. The patch may not apply 
> cleanly because I am on my testing branch, but the same change applies to 
> Master.
>
> A Crypto++ 5.6.5 change should be similar. But you should consider working 
> from Master because it has two CVE bug fixes and it is mostly stable.
>
> Jeff
>

-- 
-- 
You received this message because you are subscribed to the "Crypto++ Users" 
Google Group.
To unsubscribe, send an email to cryptopp-users-unsubscr...@googlegroups.com.
More information about Crypto++ and this group is available at 
http://www.cryptopp.com.
--- 
You received this message because you are subscribed to the Google Groups 
"Crypto++ Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cryptopp-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: error: 'mutex' in namespace 'std' does not name a type

2017-11-03 Thread Jeffrey Walton


On Friday, November 3, 2017 at 6:09:20 PM UTC-4, usbg...@gmail.com wrote:
>
> I am building CryptoPP 5.65 with MingW 6.3.0.
>
> make gives  an error:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *c:\devdir\>makeg++ -DNDEBUG -g2 -O2 -march=native -pipe -c cryptlib.cppIn 
> file included from cryptlib.cpp:19:0:misc.h: In member function 'const T& 
> CryptoPP::Singleton::Ref() const':misc.h:287:14: error: 
> 'mutex' in namespace 'std' does not name a type  static std::mutex 
> s_mutex;  ^misc.h:296:18: error: 'mutex' is not a member of 
> 'std'  std::lock_guard lock(s_mutex);  
> ^~~misc.h:296:18: error: 'mutex' is not a member of 'std'misc.h:296:28: 
> error: template argument 1 is invalid  std::lock_guard 
> lock(s_mutex);^misc.h:296:35: error: 's_mutex' 
> was not declared in this scope  std::lock_guard 
> lock(s_mutex);   ^~~make: *** 
> [cryptlib.o] Error 1*
> I ran   *make -d*   and can post that if anyone thinks that will help.
>
> What do I do to fix this?
>

If you are working on Master, then try this change: "Crypto++ MinGW 
std::mutex patch", https://pastebin.com/FqLPUj0H. The patch may not apply 
cleanly because I am on my testing branch, but the same change applies to 
Master.

A Crypto++ 5.6.5 change should be similar. But you should consider working 
from Master because it has two CVE bug fixes and it is mostly stable.

Jeff

-- 
-- 
You received this message because you are subscribed to the "Crypto++ Users" 
Google Group.
To unsubscribe, send an email to cryptopp-users-unsubscr...@googlegroups.com.
More information about Crypto++ and this group is available at 
http://www.cryptopp.com.
--- 
You received this message because you are subscribed to the Google Groups 
"Crypto++ Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cryptopp-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.