Has anyone seen this anomaly and know of a means of making the lib a
more reasonable size?
My product is an SDK, and is a DLL. I cannot get get my DLL to link
with the DLL build because I keep getting unresolved externals. I
heard on some list that the DLL version doesn't play too well when
linked by another DLL (in Visual Studio anyway). I want to use the
static library for that reason and because my DLL is the only
component of my product that will access it, so it makes sense to
statically link it anyway.
Any thoughts or suggestions?
It's not an anomaly. Just let the linker do its job. We're in the same
boat, with a DLL that links crypto++ statically The .lib file is a
similar size to what you're seeing. When you actually link that into
your dll, though, most of it is discarded. I forget now how much
crypto++ added to the size of our dll, but it was negligible in the
context of a modern windows application.
HTH,
Geoff
> It's not an anomaly. Just let the linker do its job. We're in the same
> boat, with a DLL that links crypto++ statically The .lib file is a
> similar size to what you're seeing. When you actually link that into
> your dll, though, most of it is discarded. I forget now how much
> crypto++ added to the size of our dll, but it was negligible in the
> context of a modern windows application.
Well, what do you know? You're absolutely right! My DLL ends up being
only 2M, which isn't bad. It'll be a bit tricky to work out a scheme for
dealing with the library with our Release Management people, as they
usually like putting the third-party libs in source control for our
automated builds, but I'm fine with it.
Thanks!
Brad
Learn more about Chase Paymentech Solutions,LLC payment processing services at www.chasepaymentech.com.
THIS MESSAGE IS CONFIDENTIAL. This e-mail message and any attachments are proprietary and confidential information intended only for the use of the recipient(s) named above. If you are not the intended recipient, you may not print, distribute, or copy this message or any attachments. If you have received this communication in error, please notify the sender by return e-mail and delete this message and any attachments from your computer.
-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 2.6.3
Charset: us-ascii
wsBVAwUBRs7p6muBxm7Gd4fUAQj1pQgAkRQ62HJMJPT0xeNDFob84TFr+SnHaec0
Hr0GJssydLjHFJMCWs7dhjUv+mHAIWY/nymLvY4EOU4EXQo7tQeLNrETwyq9UXNc
3g9O2ZYPgxMtjsyJp/Y/v+iQm8xseMrxQNGIgm7yTqyyC6VUcpyAVWjQZ2PbHs/P
0dTe8T3M0xIrmUkAA5fWus6quftn8NWHhcjdqO/jAji9U2ApPMJATAzZdWeBb3Ow
yev4ob5o+/4EbtMfKEXR0QLnva4T2v2OKVxYI59KxeQd7tbcn9PxGKhgQG8+6ckb
AJxARf/Y9z8Ii1wl1a5su4+CiAp3YVpRt2KCg4Pi4tCGT5ph2SxNcg==
=dNaT
-----END PGP SIGNATURE-----
The thing that I think is very odd is that the debug version is 46M
and the release version is 160M. I'm not sure if I've ever seen the
release version be larger than the debug, and defintely not by this
margin.
Is this normal as well?
That doesn't happen on my systems; release is larger than debug by
about 600K here. I do use my own project to build it, though, so it
could well be normal to have this variation.
For change control, we check the source of crypto++ (and other
libraries we depend on but don't maintain ourselves) into our SCM
system and have our autobuild system build those as well. I wouldn't
relish the idea of checking in a 45MB binary file there.
Regards,
Geoff