Is this any help with the LoaderLock exception?
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=227822&SiteID=1
On Aug 1, 9:36 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
wrote:
> 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.
-~----------~----~----~----~------~----~------~--~---
