I'm using Crypto++ V4.1 linked statically to my .EXE (see sig) and I
don't recall there being the sort of jump in size you seeing.
You can't readily equate the size of the .lib to the size of the
executable code as it contains a large amount of data which won't be
included and also .obj info is bigger than the compiled code it
produces. And there is a lot of other stuff in the .lib.
If you are doing a debug build the .dll/.exe will have lots of extra
debug info in it, which won't be present in a release build. Maybe
that's what you are seeing.
I'd suggest having a look at the VC6 .map file for the DLL which will
show you exactly what is being dragged in from the .lib.
Hope that helps.
Friday, May 16, 2003, 8:43:49 AM, you wrote:
JS> ----- Original Message -----
JS> From: "Neville Franks" <[EMAIL PROTECTED]>
JS> To: "John Stewart" <[EMAIL PROTECTED]>
JS> Cc: <[EMAIL PROTECTED]>
JS> Sent: Thursday, May 15, 2003 5:19 PM
JS> Subject: Re: trying to make my crypto++ using executable smaller
>> Hi John,
>> This doesn't make a lot of sense. You should be statically linking
>> Crypto++ to your code, and the linker should strip out everything you
>> aren't using. If you are using Crypto++ in a DLL then you will have
>> all of the code etc., but you shouldn't use it in a DLL.
JS> When you say it doesn't make any sense are you saying when you've used
JS> similar crypto++ code it has been much smaller?
JS> I am linking to crypto++ statically. My executable is a DLL but I don't
JS> see why that should keep the linker from only linking in the relevant code
JS> since I'm not exporting any part of crypto++ directly. The linker is
JS> definately doing something since cryptlib.lib is about 18 megs in size and
JS> my DLL is 450k ;) On the chance I was missing something I tried an
JS> experiment see the bottom of this post for details.
JS> I'll try to simplify and clarify the symptoms. The only crypto++ code
JS> my program uses is in the function listed below. It's straight from the
JS> crypto++ test program with exception handing added within the function and
JS> the use of the FileSource2 class. The FileSource2 class is the same as the
JS> FileSource class except that it uses C File I/O instead of C++ File I/O.
JS> Also in the DLL version the printf statements are replaced by calls to an
JS> error logging library that is used extensively throughout the rest of the
JS> program.
JS> If DO_CRYPTO is defined the resulting DLL is 450560 bytes in size. If
JS> it is not defined the resulting DLL is 225280 bytes in size.
JS> bool RSAVerifyFile(const char *pubFilename, const char *messageFilename,
JS> const char *signatureFilename)
JS> {
JS> #ifdef DO_CRYPTO
JS> try
JS> {
JS> FileSource2 pubFile(pubFilename, true);
JS> RSASSA_PKCS1v15_SHA_Verifier pub(pubFile);
JS> FileSource2 signatureFile(signatureFilename, true);
JS> if (signatureFile.MaxRetrievable() != pub.SignatureLength())
JS> return false;
JS> SecByteBlock signature(pub.SignatureLength());
JS> signatureFile.Get(signature, signature.size());
JS> VerifierFilter *verifierFilter = new VerifierFilter(pub);
JS> verifierFilter->Put(signature, pub.SignatureLength());
JS> FileSource2 f(messageFilename, true, verifierFilter);
JS> return verifierFilter->GetLastResult();
JS> }
JS> catch(CryptoPP::Exception &e)
JS> {
JS> printf("\nCryptoPP::Exception caught: %s", e.what());
JS> }
JS> catch(std::exception &e)
JS> {
JS> printf("\nstd::Exception caught: %s", e.what());
JS> }
JS> #endif
JS> return false;
JS> }
JS> To test the theory of the linker behaving differently when building a
JS> DLL as opposed to building an EXE I built a test executable including the
JS> above function and the below main:
JS> int main()
JS> {
JS> printf("result=%d\n", RSAVerifyFile("foo", "bar", "sig"));
JS> return 0;
JS> }
JS> If DO_CRYPTO is defined the size is: 286720 bytes
JS> If DO_CRYPTO is not defined the size is: 73728 bytes
JS> So in the case of the DLL adding the signature verification codes adds
JS> 225280 bytes to the size.
JS> And in the case of the EXE adding the signature verification codes adds
JS> 212992 bytes to the size.
JS> Not a huge difference there. It looks like the linker is doing an
JS> approximately equal job in both cases.
JS> More details:
JS> All reported sizes in the above are compiled with MSVC 6.0 service pack
JS> 5.
JS> Optimization setting is maximize speed.
JS> The run-time library option is plain old Multithreaded(not Multithreaded
JS> DLL). I.e. statically linked CRT.
JS> __cdecl calling convetion, 8 byte structure alignment and processor is
JS> set to the default of Blend.
JS> Thanks again,
JS> John Stewart
--
Best Regards,
Neville Franks, Author of ED for Windows - the programmer's editor.
Soft As It Gets Pty Ltd, http://www.getsoft.com - Download your Free Trial now.
Victoria, Australia mailto:[EMAIL PROTECTED]
