Is static linking of the runtime dangerous for plugins?

#1

What's the preferred thing to do? I saw this over on SO:

"Using /MT is risky if you create DLLs as well as an EXE. You'll end up with multiple copies of the CRT in your program. This was especially a problem with earlier versions of VS where each CRT would get its own heap, not so much with VS2012. But you can still have ugly runtime problems when you have more than one "errno" variable for example. Using /MD is highly recommended to avoid such lossage."

From http://stackoverflow.com/questions/14749662/microsoft-visual-studio-c-c-runtime-library-static-dynamic-linking

thanks!

#2

Wouldn't have thought it's too dangerous, even if it does create a different heap for each DLL.. In a plugin environment, that could actually be an advantage, since your own plugin's heap won't be overwritten by other misbehaving plugins.

But I really couldn't confidently say what the "correct" thing to do would be - opinions welcome from people who've tried it!

#3

/MT seemed the least troublesome option when i looked at it.

#4

I've been using the statically linked crt for years for vst / rtas and  aax windows plugins , it's never been a problem

#5

Actually there is a limit on how many staticly linked (using /MT) .dll's can be loaded by the host.
The host process can only load 128. We actually ran into this issue because all our build in effect plugins (FFGL video plugins) are actually dlls. So we started using /MD and installing the right visual studio runtime dll's when installing our application. So from the host point of view /MT can cause problems but only if there are a lot of plugins.

Some info on this can be found here:
https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/3546c3c4-1b36-4552-85c5-1b3ba860ee84/how-many-dlls-can-be-loaded-in-a-process-using-loadlibrary-?forum=windowssdk