Linking static libraries to VS2005 Managed C++ DLL

[mmsin...@gmail.com]

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

[Parch]

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, "mmsincl...@gmail.com" <mmsincl...@gmail.com>
wrote:

[mmsin...@gmail.com]

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

> > Mark- Hide quoted text -
>
> - Show quoted text -

[Parch]

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, "mmsincl...@gmail.com" <mmsincl...@gmail.com>