0

I Just tried to build a x64 C++ DLL using Visual C++ 2012. It's a simple DLL linking one other static third-party .lib file. I am getting the following warning message:

warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library

It seems that other library uses /MT (multithreaded static runtime) linker option while my DLL (and all the other projects importing my DLL) uses /MD (multithreaded DLL runtime). I can not harmonize this since the third-party lib is delivered as it is and changing my DLL would create the same problem in all projects using my DLL.

I read some pages from MS and forums about this problem. But non of these pages explained what exactly is the problem here.

What I do not understand:

What is the harm in linking code that uses different runtime variant (other than wasting memory)? Some people say this can be ignored, some say it may not.

Is it ok to use /NODEFAULTLIB[:library]? The documentation says it would "remove a specified library or libraries from the list of libraries it searches when resolving external references". Which library should I add as ":library" and in which way does this solve the problem?

Peter Bloomfield
  • 5,578
  • 26
  • 37
Silicomancer
  • 8,604
  • 10
  • 63
  • 130

2 Answers2

3

Conflicting run-time libraries can cause serious problems if you are sharing C run time objects (items such as FILE*) or sharing memory allocations (allocating memory in one part and deallocating it in another). I would avoid "forcing" them together to avoid weird problems and crashes.

Instead, if you cannot change the build of the lib or of your dll, I would wrap the lib inside a dll with a C only interface that doesn't leak any C runtime object or require you to free memory outside of the dll that was created inside.

villintehaspam
  • 8,540
  • 6
  • 45
  • 76
  • The library already has a plain C API. And as far as I know there is no need to share allocated memory since the DLL supplies all need creation and desctruction functions. Seems the lib already fulfils your rules for safe usage. However how do I get rid of the annoying warning? And which effect would /NODEFAULTLIB[:library] have? – Silicomancer Oct 31 '13 at 17:09
  • I would still wrap it into a dll. I would think that this will likely be the easiest path forward. – villintehaspam Oct 31 '13 at 22:03
  • It turns out that a wrapper DLL is not allowed by license. This gets complicated. I wonder if ignoring the warning could be acceptable given that no memory allocations are shared. Is there any more problem that could arise not mentioned here? – Silicomancer Nov 01 '13 at 19:23
  • Build enough features into your wrapper dll that it meets the requirements for the license (i.e. move functionality from your current dll into the "wrapper"). If you can't do that then you probably aren't allowed to build your dll anyway. I don't recommend ignoring warnings. Otherwise rework the interface you provide in your dll - you say that you have a simple C++ dll - make it a simple C dll then and provide wrapper classes (likely header only) in C++ if you want. – villintehaspam Nov 01 '13 at 19:55
  • Yes. I think I can solve this that way. Unfortuantely there are also Executeables that include that static linker library. So I will find a similar solution for this too. Thanks for your help! – Silicomancer Nov 01 '13 at 21:34
3

For example passing STL types (e.g. std::string) could lead to major crashes due to differnce in the internal object layout and/or memory disposal

See Why does this program crash: passing of std::string between DLLs

Community
  • 1
  • 1
Shmil The Cat
  • 4,548
  • 2
  • 28
  • 37