Re: Conflicting C Runtimes can of worms
Murrgon wrote:
1) If I have a DLL that uses the shared/dll version of the CRT, but
links with a library that uses the static version of the crt, what do
you end up with? (Besides linker warnings). Does the code the
library depend on actually get linked in to the DLL?
You'll get linker errors/warnings due to conflicting symbols. Usually, the
only correct way to resolve this is to use the /NODEFAULTLIB linker option
to suppress all CRT selections baked into the code, then explicitly link in
the version of the CRT that you need. If you _need_ version X and the
library _needs_ version Y, then you'll need to split code into two or more
DLLs, each depending on exactly one version of the CRT.
2) Same situation as above, but you've told your DLL to ignore
libcmt(d).lib. Will this force the linker to ONLY use the shared/dll
version of the CRT, despite the other lib saying otherwise?
If you've used /NODEFAULTLIB to suppress default dependencies to particular
libraries, any remaining default references to other libraries will still be
honored by the linker (and may still result in conflicts - e.g. the code
could be trying to default link 3 or more different CRT flavors).
3) What are the dangers of having one DLL using the shared/dll
version of the CRT and another that has been statically linked with
the CRT? This can happen often when using 3rd party DLLs that don't
provide the source to build it.
No danger if objects allocated in one DLL always remain within that DLL. If
any object allocated in one DLL are shared with code in another DLL, you'll
likely have problems - unless the sharing is through pure interfaces, such
as with COM components.
-cd