Site navigation

Is static linking of the runtime dangerous for plugins?

Windows
#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

 

 

#6

Sorry for replying to old post… but wait a minute. When I Try to build AAX with static runtime it won’t work. Is this a change that it’s forced now or do I have some problem with my configuration and I SHOULD be able to build static runtime AAX?

1 Like
#7

There was this change in the meantime, but not specific to AAX though.
Thought I link there (no pun intended)

#8

Yeah I’m aware of this change but I never got AAX built with static runtime even before this. By the way, I’m still building other formats staticly even tho I know about this limitation, because static plugins require hugely less disk space and load faster. We build large samplers and the disk space difference is hundreds of megabytes so… Just gotta embrace possible issues with this. But yeah, AAX doesn’t work for me “staticly built”. Error message is:

2>LINK : warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library
2>H:\xxxxxx\\xxxxx.aaxdll : fatal error LNK1319: 18 mismatches detected
========== Build: 1 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
#9

So maybe I have built AAX SDK with dynamic setting, and that’s why I Can’t build static AAX?

#10

Ok I don’t know again what happened but now I managed to build static AAX. lol.