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

[usb...@gmail.com]

I am building CryptoPP 5.65 with MingW 6.3.0.

make gives  an error:

c:\devdir\>make
g++ -DNDEBUG -g2 -O2 -march=native -pipe -c cryptlib.cpp
In file included from cryptlib.cpp:19:0:
misc.h: In member function 'const T& CryptoPP::Singleton<T, F, instance>::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<std::mutex> 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<std::mutex> lock(s_mutex);
                            ^
misc.h:296:35: error: 's_mutex' was not declared in this scope
  std::lock_guard<std::mutex> 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?

[Jeffrey Walton]

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

[usb...@gmail.com]

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

[usb...@gmail.com]

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                   565            fail
630                   562            fail
472                   565            fail
472                   562            works 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

[Jeffrey Walton]

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                   565            fail
630                   562            fail
472                   565            fail
472                   562            works 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

[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

[Jeffrey Walton]

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

[Jeffrey Walton]

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

Jeff

[Jeffrey Walton]

On Sunday, November 5, 2017 at 5:08:08 PM UTC-5, Marcel Raad wrote:

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

Jeff

[Jeffrey Walton]

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                   565            fail
630                   562            fail
472                   565            fail
472                   562            works 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

[usb...@gmail.com]

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

[Jeffrey Walton]

On Mon, Nov 6, 2017 at 9:28 AM, <usb...@gmail.com> 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 >= 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.

Jeff

[usb...@gmail.com]

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 <wspiapi.h>
                       ^
compilation terminated.
make: *** [socketft.o] Error 1

I will check out my MingW options.

Thanks,

Gene

[Marcel Raad]

Hi Gene,

Am 06.11.2017 18:55 schrieb <usb...@gmail.com>:

g++ -DNDEBUG -g2 -O3 -pthread -pipe -c socketft.cpp
socketft.cpp:36:23: fatal error: wspiapi.h: No such file or directory
 #  include <wspiapi.h>
                       ^
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

[Jeffrey Walton]

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 <wspiapi.h> 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

[Marcel Raad]

Hi Jeff,

Am 06.11.2017 19:29 schrieb "Jeffrey Walton" <nolo...@gmail.com>:

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

[Jeffrey Walton]

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 <sanitizer/msan_interface.h>
 #endif

+// From http://groups.google.com/d/msg/cryptopp-users/MzvocLrbIpE/TMCa6LFhCgAJ,
+// <wspiapi.h> 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

[Marcel Raad]

Hi Jeff,

Am 06.11.2017 20:20 schrieb "Jeffrey Walton" <nolo...@gmail.com>:

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 <sanitizer/msan_interface.h>
 #endif

+// From http://groups.google.com/d/msg/cryptopp-users/MzvocLrbIpE/TMCa6LFhCgAJ,
+// <wspiapi.h> 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

[usb...@gmail.com]

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 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
g++: error: unrecognized command line option '-template=no%extdef'; did you mean '-ftemplate-depth-'?
Reaping losing child 0x0219fa00 PID 35177856

make: *** [cryptlib.o] Error 1

Removing child 0x0219fa00 PID 35177856 from chain.

[Jeffrey Walton]

On Tue, Nov 7, 2017 at 1:53 PM, <usb...@gmail.com> 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

[Jeffrey Walton]

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.

For what it is worth, I cannot duplicate the issues using the latest MinGW-64 and Master. Here's a pastebin of the build from a 64-bit prompt: https://pastebin.com/d3jzSi2B.

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.

Jeff

[Marcel Raad]

Am 08.11.2017 00:29 schrieb "Jeffrey Walton" <nolo...@gmail.com>:

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