Thanks for pointing out the compile problems with STLport. I'll put a fix in 
the next release.

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.

#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.
-~----------~----~----~----~------~----~------~--~---

Reply via email to