Wei Dai wrote:
> Thanks for pointing out the compile problems with STLport. I'll put a
> fix in the next release.
Thanks - I will watch for changes in the SVN trunk on these files. In
general, when you commit something to your SVN server, should it be
expected to leave the tree in a buildable condition?
> As for the iostream usage, I don't think the linker should pull it in if
> you're just using the three hash functions. Using the following test
> program, I get an executable size of 151,552, which is less than the
> 200k that you cite. This is using the same project settings as
> cryptest.vcproj. I'll take another look and see if the size can be
> reduced further.
Thanks again for this - I will review my results and attempt to
duplicate your (or my) results with your minimal test case. To be clear
- you do NOT expect to need iostreams if all that is being used are the
hash functions? Might there be an issue with Crypto++ -defined
exceptions (like default handlers with iostream output or some such)?
Finally, should I be able to build the Crypto++ library (not the test
program project) using STLport in "_STLP_NO_IOSTREAMS" mode? Because
that seems to not be working, in that I get a compile-time error from
STLport that is [apparently] triggered off of *some* reference to
iostreams...
BTW, the speed of these hash funcs is really impressive - my previous
implementation (from LibTomCrypt) fell down badly on the SHA-512, and
particularly Whirlpool; neither could keep up with disk reading speeds
of ~65 MB/s, but the Crypto++ versions are faster than disk (as noted in
the OP, 77 MB/s for Whirlpool!).
> #include "sha.h"
> #include "md5.h"
> #include "whrlpool.h"
>
> USING_NAMESPACE(CryptoPP)
> USING_NAMESPACE(std)
>
> extern int (*AdhocTest)(int argc, char *argv[]);
>
> int main(int argc, char *argv[])
> {
> SHA sha;
> MD5 md5;
> Whirlpool w;
> byte a[100];
> sha.CalculateDigest(a, a, 0);
> md5.CalculateDigest(a, a, 0);
> w.CalculateDigest(a, a, 0);
> return 0;
> }
>
> --------------------------------------------------
> From: "Robert Roessler" <[EMAIL PROTECTED]>
> Sent: Thursday, September 13, 2007 9:02 PM
> To: "Crypto++" <[EMAIL PROTECTED]>
> Subject: Re: Compiling SVN trunk with VS 2005 SP1
>
>>
>> Robert Roessler wrote:
>>> I am considering using Cpypto++ for the hashing (and possibly RSA-1024
>>> signature verification). As I have noticed the occasional bug fix
>>> mentioned here, I pulled the SVN trunk source and set out to build it
>>> with my VS 2005 SP1 installation. Note that I am also using the 5.1.3
>>> STLport release from April (the latest).
>>>
>>> For cryptopp, I did a "configure -c msvc8 --no-rtti", followed by a
>>> Release build of the cryptest project in Visual Studio.
>>
>> Maybe I now see why no one has had any comments: the above "configure"
>> is from STLport, which I was forced to actually build because Crypto++
>> uses iostreams (my own use of STLport involves no iostreams, so I get to
>> use it in "headers-only" mode) - but everything else is just about
>> Crypto++. ;)
>>
>>> I encountered 2 compile-time errors that required source adjustments -
>>> at least that is how *I* got around them... ;)
>>>
>>> In fipstest.cpp line #282, I forced the #if to always be FALSE, since
>>> STLport doesn't seem to support ifstreams with wide filenames.
>>>
>>> In zdeflate.cpp line #388, I also forced the #if to always be FALSE (but
>>> just because it seemed expedient).
>>>
>>> Finally, the following 8 warnings were issued:
>>>
>>> rng.cpp(108) : warning C4789: destination of memory copy is too small
>>> twofish.cpp(69) : warning C4789: destination of memory copy is too small
>>> seal.cpp(65) : warning C4789: destination of memory copy is too small
>>> seal.cpp(65) : warning C4789: destination of memory copy is too small
>>> algebra.cpp(122) : warning C4789: destination of memory copy is too
>>> small
>>> algebra.cpp(122) : warning C4789: destination of memory copy is too
>>> small
>>> algebra.cpp(293) : warning C4789: destination of memory copy is too
>>> small
>>> algebra.cpp(293) : warning C4789: destination of memory copy is too
>>> small
>>>
>>> The validation run had no failures, and the benchmark run looked very
>>> good relative to your posted Pentium 4 numbers... and not so great
>>> compared to your Opteron numbers (I was using a Core 2 Duo @ 2.4 GHz) -
>>> but my Whirlpool was better than the Opteron (63 vs 77). :)
>>
>> But I am still left with a bizarre situation where Crypto++ insists on
>> using iostreams somewhere - and that seems to be just the library
>> itself, even if I just build that without the test program?
>>
>> Weirder than this is an *apparent* serious lack of modularity... this
>> translates to my app growing by almost 200KB, just using the md5, sha*
>> and whirlpool hashes, and when compared to LibTomCrypt using the same
>> hashes.
>>
>> So, IS the iostream stuff required by [only] the Crypto++ hashing code,
>> and if so, can I do anything about it?
>>
>> AND, is there something I am missing config-option-wise that would help
>> in just pulling in the parts of Crypto++ (and the C++ runtime libs) that
>> I really want?
Robert Roessler
[EMAIL PROTECTED]
http://www.rftp.com
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the "Crypto++ Users"
Google Group.
To unsubscribe, send an email to [EMAIL PROTECTED]
More information about Crypto++ and this group is available at
http://www.cryptopp.com.
-~----------~----~----~----~------~----~------~--~---
