Hi Parch
Thanks, all of your suggestions have been very useful and helpful!! I
suspect there are two different new/delete operators in two different
stdlibs.
I built a static version of Crypto++ using Unicode Multithreaded DLLs
and that seems to be much better when linking to the managed DLL. I
still get some odd errors when the DLL unloads, but it seems if I let
the compiler include Crypto++ without explicitly saying it is
unmanaged code, then everything is ok. If I force it to be unmanaged
(#pragma unmanaged) then when Crypto++ uninitialises it can't delete
things properly or I get a LoaderLock exception. I think this is just
a minor imcompatibility and I hope it doesn't cause a memory leak.
I am busy with an article for codeproject.com because this seems to be
a common problem for many people.
Again, thanks for all your help.
Regards
Mark
On Jul 31, 12:17 pm, Parch <[EMAIL PROTECTED]> wrote:
> Hi Mark,
> What I have heard: linking with 2 different C runtime libraries is
> usually not recommended, although it may sometimes work OK (your
> mileage may vary).
> (I wonder if 2 different C runtimes gives you two different new/delete
> operators to link with for instance....?)
>
> The linking error comes from the C runtimes:
> It's not Crypto++ which is referencing int main(...), rather it is the
> C runtime libraries that you link with (they normally initialize
> internal data structures, convert parameters etc, then call main, and
> your program begins). It sounds like you are explicitly linking with
> one ascii, and one unicode C runtime. The ascii one will probably
> expect an int main(int, char....) to link with, and the unicode one
> will probably expect an int main(int, wchar...) to link with. I am
> guessing your managed code provides the second version, but not the
> first. You may be able to make your project compile by defining a
> dummy int main(int, char...) for the linker to find - or forcing the
> linker to generate the code anyway with unresolved references - but I
> don't know how to guarantee which main function will actually be
> called when your program starts up.
>
> I think the proper way to fix your problem is to build a version of
> Crypto++ which uses the same C runtime as your managed DLL, by
> changing the Crypto++ settings for code generation (maybe to debug
> multithreaded dll? not sure) and character set (to UNICODE?), and then
> any Unicode specific stuff for Crypto++.
>
> Hope this is helps one way or the other,
> Parch
>
> On Jul 30, 8:10 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> wrote:
>
>
>
> > Hi everyone
>
> > I am trying to link the static lib build of Crypto++ 5.51 built with
> > Visual Studio 2005 to a Managed Class Library (DLL). Has anyone else
> > tried to link a static version of Crypto++ to a VS2005 managed C++
> > class? If so, I was hoping someone could help me resolve the linking
> > issues I am having.
>
> > I am including Crypto++ as follows into a simple DLL created from the
> > project wizard:
>
> > // test.h
>
> > #pragma once
>
> > // Crypto++
> > #define CRYPTOPP_DEFAULT_NO_DLL
> > #include "default.h"
> > #include "base64.h"
> > #include "osrng.h"
> > #include "rsa.h"
>
> > using namespace CryptoPP;
>
> > // Managed C++
> > using namespace System;
>
> > namespace test {
>
> > public ref class Class1
> > {
> > // TODO: Add your methods for this class here.
> > };
>
> > }
>
> > The linker reports lots of conflicts with libcmt and mscvrt however I
> > can resolve these by adding /FORCE:MULTIPLE to the linker command line
> > properties. The only linking issue I cannot solve is this:
>
> > LIBCMTD.lib(crt0.obj) : error LNK2019: unresolved external symbol
> > _main referenced in function ___tmainCRTStartup
>
> > What in Crypto++ is running int main(...)? I realise as well that
> > Crypto++ is built is a non-Unicode project and the Managed DLL is
> > built with Unicode libraries, so the true entry point is the Unicode
> > main function. If I define a main function I get some interesting
> > errors when loading the DLL from tester applications.
>
> > Another option I have tried is to use the DLL build of Crypto++. I
> > have had more luck with this, although there are some odd problems I
> > have had with the Base64 encoder when it is destroyed which I think
> > had to do with using the wrong delete operator pointer. But that is
> > probably something for a seperate post!
>
> > Any help would be appreciated!
>
> > Many thanks
> > Mark- Hide quoted text -
>
> - Show quoted text -
--~--~---------~--~----~------------~-------~--~----~
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.
-~----------~----~----~----~------~----~------~--~---
