Re: error: 'mutex' in namespace 'std' does not name a type
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
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
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: Skipping last few bytes of file when FileSource
On Sunday, November 5, 2017 at 10:00:06 AM UTC-5, Richard Závodný wrote:
>
> Hi. I need skip last 512bytes from the file. This solution not working:
> int fileSize = boost::filesystem::file_size("first.txt");
>
> CryptoPP::FileSource sourceFile("first.txt", false, new CryptoPP::FileSink
> ("second.txt"));
> sourceFile.Pump(fileSize - 512);
>
> How could i achieve this?
>
Pump as many bytes as you wish. Then, call sourceFile.Skip(...) to skip the
bytes.
Also see BufferedTransformation in the docs at
https://www.cryptopp.com/docs/ref/class_buffered_transformation.html.
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
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
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
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
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) ||
> (_WIN32_WINNT >= 0x0
Re: error: 'mutex' in namespace 'std' does not name a type
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
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
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
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: Skipping last few bytes of file when FileSource
Okay. I think, there is another problem. The file is actually splitted into
two parts. First is encrypted content using AES and the second is encrypted
Aes Key and Iv using RSA. The encrypted Aes Key and Iv is 512 bytes big on
the end. First I needed to get 512 bytes from the end, decrypt using RSA
then I get the AES key and iv. That isn't problem. I did what you proposed.
Code following:
CryptoPP::FileSource sourceFile("first.txt", false, new CryptoPP::
StreamTransformationFilter(cbcDecryptor, new CryptoPP::FileSink("second.txt"
)));
sourceFile.Pump(fileSize - 512); //Fetch only encrypted content with AES
(without the RSA encrypted key)
sourceFile.Skip(512); //Skip last 512 bytes
But when I do this, the problem occur. My decrypted file is 15 bytes
shorter and I don't know why! Original file size is 351 bytes, encrypted is
864 bytes (351 bytes + 1byte AES padding + 512 bytes key), decrypted file
size is 336 bytes.
On Monday, 6 November 2017 14:37:30 UTC+1, Jeffrey Walton wrote:
>
>
>
> On Sunday, November 5, 2017 at 10:00:06 AM UTC-5, Richard Závodný wrote:
>>
>> Hi. I need skip last 512bytes from the file. This solution not working:
>> int fileSize = boost::filesystem::file_size("first.txt");
>>
>> CryptoPP::FileSource sourceFile("first.txt", false, new CryptoPP::
>> FileSink("second.txt"));
>> sourceFile.Pump(fileSize - 512);
>>
>> How could i achieve this?
>>
>
> Pump as many bytes as you wish. Then, call sourceFile.Skip(...) to skip
> the bytes.
>
> Also see BufferedTransformation in the docs at
> https://www.cryptopp.com/docs/ref/class_buffered_transformation.html.
>
> 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: Skipping last few bytes of file when FileSource
On Monday, November 6, 2017 at 2:27:30 PM UTC-5, Richard Závodný wrote:
>
> Okay. I think, there is another problem. The file is actually splitted
> into two parts. First is encrypted content using AES and the second is
> encrypted Aes Key and Iv using RSA. The encrypted Aes Key and Iv is 512
> bytes big on the end. First I needed to get 512 bytes from the end, decrypt
> using RSA then I get the AES key and iv. That isn't problem. I did what you
> proposed. Code following:
> CryptoPP::FileSource sourceFile("first.txt", false, new CryptoPP::
> StreamTransformationFilter(cbcDecryptor, new CryptoPP::FileSink(
> "second.txt")));
> sourceFile.Pump(fileSize - 512); //Fetch only encrypted content with AES
> (without the RSA encrypted key)
> sourceFile.Skip(512); //Skip last 512 bytes
>
> But when I do this, the problem occur. My decrypted file is 15 bytes
> shorter and I don't know why! Original file size is 351 bytes, encrypted is
> 864 bytes (351 bytes + 1byte AES padding + 512 bytes key), decrypted file
> size is 336 bytes.
>
It sounds like data is being buffered: 351 -336 = 15.
Try calling sourceFile.MessageEnd(). If you get an exception, then you will
need to use a different technique.
Since you are at the end of your data stream you may be able to induce a
MessageEnd() with a call to PumpAll().
You can wrap the code above in a C++ block to cause the destructors to run,
which will implicitly call MessageEnd():
{
FileSource sourceFile("first.txt", false, ...);
sourceFile.Pump(fileSize - 512);
sourceFile.Skip(512);
}
If you want to explicitly control MessageEnd(), then use the following. It
is how the library does it when needed:
StreamTransformationFilter* x = NULL;
FileSource sourceFile("first.txt", false, x=new
StreamTransformationFilter(...));
sourceFile.Pump(fileSize - 512);
sourceFile.Skip(512);
x->MessageEnd();
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
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.
