eccrypto.cpp implements elliptic curve cryptography. fipstest.cpp implements FIPS 140-2 required power up self test. If you don't use either of these you can remove them from your project which will allow you to remove hex.cpp.
Let me suggest that instead of putting everything in and then trying to remove the stuff you don't need, to put in the files you know you need, and then adding more to satisfy linker requirements. But you should only do this if you need to frequently recompile Crypto++. Otherwise you should just compile the whole Crypto++ into a static library and let the linker throw out unneeded modules at link time. On Wed, Jul 16, 2003 at 07:59:31PM +0900, [EMAIL PROTECTED] wrote: > Hello, > > As for hex.cpp, removing it from project I got the following from > the linker (VC++7.1, sorry for unformatted spam): > > eccrypto.obj : error LNK2019: unresolved external symbol "private: static int const > * __cdecl CryptoPP::HexDecoder::GetDecodingLookupArray(void)" ([EMAIL > PROTECTED]@CryptoPP@@CAPBHXZ) referenced in function "public: __thiscall > CryptoPP::HexDecoder::HexDecoder(class CryptoPP::BufferedTransformation *)" ([EMAIL > PROTECTED]@@[EMAIL PROTECTED]@1@@Z) > fipstest.obj : error LNK2001: unresolved external symbol "private: static int const > * __cdecl CryptoPP::HexDecoder::GetDecodingLookupArray(void)" ([EMAIL > PROTECTED]@CryptoPP@@CAPBHXZ) > fipstest.obj : error LNK2019: unresolved external symbol "public: virtual void > __thiscall CryptoPP::HexEncoder::IsolatedInitialize(class CryptoPP::NameValuePairs > const &)" ([EMAIL PROTECTED]@CryptoPP@@[EMAIL PROTECTED]@@Z) referenced in function > "public: __thiscall CryptoPP::HexEncoder::HexEncoder(class > CryptoPP::BufferedTransformation *,bool,int,class _STL::basic_string<char,struct > std::char_traits<char>,class _STL::allocator<char> > const &,class > _STL::basic_string<char,struct std::char_traits<char>,class _STL::allocator<char> > > const &)" ([EMAIL PROTECTED]@@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL > PROTECTED]@std@@[EMAIL PROTECTED]@_STL@@@_STL@@[EMAIL PROTECTED]) > > What I was doing is RSA pub key en/decryption, AES block cipher > en/decryption, random number generation by the wrapper to > CryptoAPI, and using Integer for public key management. All operations > are done in raw binary, plain StringSink without encoding. > I have no idea what eccrypto does in my context and have little > knowledge about Crypto++ internal, but in removing files that are not > necessary in link stage, I had to include 47 source .cpp files of Crypto++ > into my project... It includes even des.cpp to achieve the task described > at above :) > > Best, > Kenneth > > On Wed, 16 Jul 2003 01:22:48 -0400 > Wei Dai <[EMAIL PROTECTED]> wrote: > > > It's a valid point, and I'll do what I can and welcome suggestions. > > > > The iostream issue is easy enough. I'll move the iostream related > > functions into separate files. > > > > If you take out hex.cpp, the linker should tell you which .obj file > > depends on it. Please provide me what that info. > > > > There is already a way to remove dependencies on windows.h/winsock2.h. > > Just #define NO_OS_DEPENDENCE in your project/make file or in config.h. > > > > On Wed, Jul 16, 2003 at 08:44:21AM +0900, Kenneth L. wrote: > > > Hello, > > > > > > One thing I feel concern about Crypto++ these days is its > > > dependency to platform-specific tools, such as sockets > > > and file operations, though it's a bit misleading to call > > > it as "dependency". It contains very useful tools for > > > those who use them, but for others, that dependency > > > sometimes increases build time very much and call in > > > other unwanted effects. I use Crypto++ as neither > > > static nor dynamic lib, but rather I use it per class to get > > > necessary functions, because I sometimes modify STL > > > itself that is also used in Crypto++, or add whole > > > program optimization to make executable size smaller. > > > > > > For example, basic class such as integer.h/cpp includes > > > iosfwd/iostream and you need iostream at link time. > > > iostream is one of C++ standard, but very dependent on > > > platform and library implementation, as you find old > > > iostream / new iostream, SGI iostream, and so on. > > > Another example is socket-related, in Windows, > > > winsock2.h/winsock.h/windows.h/mswsock.h/ws2tcpip.h > > > conflict occurs even when I use none of those network > > > sink in Crypto++. More obscure problem is, I need to link > > > to hex.cpp though all stages in my use of Crypto++ > > > there's apparently no operation that requires hex encoding/ > > > decoding! > > > > > > If Crypto++ is pure algorithmic/arithmetic collection, it will have > > > algorithms in pure / lightweight form like STL <algorithm> and > > > should have other sink/source interface helpers separated from > > > algorithms themselves. In my observation, current Crypto++ > > > abstracts them, but not separates / encapsulates them in > > > effective manner. > > > > > > To sum it up, is there any future design plan of Crypto++ for this > > > issue of lightweightness/less-dependency/shorter-build-time? > > > > > > > > > Best, > > > Kenneth > > > > > > > >
