views:

91

answers:

1

Hello.

I have written an application in VS C++ 2010 Express Edition which consists of some DLLs and also depends on some third party DLLs. The application itself is a DLL.

As it turned out, to make it work on another machine, user has to install VS 2010 redistributable runtime.

I tried to build my DLL with flag /MT instead of /MD - I believe this means that I want static linking.. However, in this case I got 'multiple definition' errors about MSCVRT.lib. Error message also suggested to use flag /NODEFAULTLIB:msvcrt.lib to avoid this. However, with these settings my application still requires runtime installation.

Could somebody please explain me how to avoid this?

Thanks, Robusta

Update: if I simply use /MT flag instead of /MD I get the following error

MSVCRT.lib(ti_inst.obj) : error LNK2005: "private: __thiscall type_info::type_info(class type_info const &)" (??0type_info@@AAE@ABV0@@Z) already defined in LIBCMT.lib(typinfo.obj) MSVCRT.lib(ti_inst.obj) : error LNK2005: "private: class type_info & __thiscall type_info::operator=(class type_info const &)" (??4type_info@@AAEAAV0@ABV0@@Z) already defined in LIBCMT.lib(typinfo.obj) Creating library C:\MyApp\Release\MyApp.lib and object C:\MyApp\Release\MyApp.exp LINK : warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library C:\MyApp\Release\MyApp.dll : fatal error LNK1169: one or more multiply defined symbols found

after adding flag /NODEFAULTLIB:library I get no errors, application is built successfully, but still requires runtime installation.

Is it possible that 3rd party libraries, which I also link, require runtime?

+2  A: 

You are linking in some code that is still compiled with /MD, possibly some kind of static library. Mixing and matching doesn't work.

Using /MT when you use DLLs is very dangerous. You'll get in trouble when the exported functions return a pointer or a C++ object that needs to be released by the client code. Returning an std::string for example. With /MT, the client will use its own heap allocator to release the memory. Cannot work, the DLL used another heap. You'll leak, very hard to diagnose. Using 3rd party DLLs that were built with a different version of the CRT is a problem for the same reason. There's more details in this MSDN Library article.

Deploying the required CRT DLLs is pretty simple with this download.

Hans Passant
Thanks for the warning., so your advice is just to admit the fact that redistributable installation is required?
If you haven't explicitly designed the DLL exports to be robust against this problem (COM for example) then, yes, don't mess around with it. That's 5 minutes of your time that's nothing compared to what it will take to trouble-shoot either the linker or memory problems. You appear to be using 3rd party code that expects to have the shared CRT available, it almost certainly wasn't tested with /MT.
Hans Passant