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 > > > >
