VST with /MD (CRT multi-threaded DLL) can't find MSVCP90.dll


#1

Hi !

I am writing a win32 VST-plugin, originally generated with the Jucer(experimental). I’ll call it “MyVst” in this post…
Among other things, it is linked statically with “Security.lib” (a security tool library provided by my company, which I am obviously bound to use, and upon which
I have almost no control…) Security.lib is compiled with the /MD (/MDd in Debug…) command line option (that means, linked dynamically with the CRT)

Jucer’s generated projects use statically linked CRT by default (/MT and /MTd), but it turns out it won’t link properly this way. MyVst complains about hundreds of error LNK2005 (basically : “Some stuff in MyVst is already defined in Security.lib. I’m a stupid linker that doesn’t know how to deal with it…”)
Ignoring the specific CRT libraries that the linker complains about (typically libcmt[d].lib, msvcrt[d].lib) doesn’t help : I get LNK2001 instead (“Boooh, I can’t find the definition of some stuff…”)

So, I thought I might just as well change MyVst’s settings to /MD (/MDd in debug). After all, this vst is never going to be released without the security suite that includes the DLLs for the CRT anyway, so it’ll just reduce the size of my dll, which is fine, as far as I am concerned… I did so, it compiled and linked all right, but at runtime, only the Debug version is working. The Release version has different odd behaviours, depending on the VST-Host I try to load MyVst.dll in…

Looking at the MyVst.dll (the release version) with Dependency Walker shows it can’t find MSVCP90.dll…

I tried MyVst_dbg.dll (the functionnal debug version) with DependencyWalker, for comparison. He says it’s ok : MyVst does need MSVSP90D.dll (the corresponding debug version) but he’s happy, he knows where it is : deep down in some C:\windows\winsxs… subfolder. And just in the neighbour folder, with basically the same name except it hasn’t “debug” in it, guess who I found ? MSVCP90.dll : the mysterious dll that Dependency walker, and presumably all my VSTHosts, weren’t able to find for the release version.

I’ve also been checking my projects settings, looking for differences between Debug and Release configurations, but I could spot nothing suspicious (probably because I don’t really know what I am looking for anyway…) Only thing maybe worth mentioning : in debug, the Jucer wants to ignore libcmt.lib and msvcrt.lib, and there’s nothing corresponding in release configuration. It seemed odd to me : why would I want to specifically ignore release-library in debug mode ? Nobody is going to try to link on them anyway. (And removing it doesn’t seem to change anything, btw, and didn’t solve my problem…)

So, I don’t really know what to try next… Any help would be welcome !

Val

(And just in case : Win32, Visual C++ 2008, Juce 1.52…)


#2

Okay… I solved it all alone !

If anybody cares : the release version of the VST didn’t generate a manifest (only debug version did) This isn’t a problem on a plugin linked statically to the CRT (it doesn’t need to search for the runtime : it is right here in the dll.) But is an issue if the plugin is linked dynamically to the CRT, as the plugin relies on the manifest to find the dlls it depends on.

If I may formulate a feature request : the jucer’s configuration should enable the user to pick what CRT linking setup we want to use. (/MT, /MD) and in the best possible world, if it could even deal with the manifest thing…

Anyway : at least I’m out of trouble…

Cheers !

Val


#3

Edit : double post removed - sorry…


#4

Yes, good request - if I don’t do it soon, please remind me!


#5

Hi Jules !

Great if you can do it… I was thinking : while you are at it, you can probably also do some cleanup and remove the “lib to ignore”

or maybe it is necessary to have those ignored, and in this case, if you could shortly explain why…

Anyway, thanks for these awesome tools you provide !

Val


#6

The ignored lib was definitely necessary… But I’m afraid I did that several years ago and can’t remember the exact reason. I think it was because the RTAS libs were built with a different setting or something…


#7

the last time we tried fiddling around with the linker settings, we were able to succsfuully build RTAS-Plugins on Windows with “/NODEFAULTLIB:libcmt.lib” set only in Release configuration.

That was with VS2005 using the PT_80_SDK.


#8

It is planned that this VST is ported to RTAS (not immediately, though) When I do so, I’ll take the time to try and tweaki a few things with /NODEFAULTLIB and other compile/link settings. Will keep you posted…

Thanks for your help anyway !

Val


#9

Yes, good request - if I don’t do it soon, please remind me![/quote]

Hi! I’m a friendly reminder!

In an ideal world, the manifest thing would be properly dealt with when building RTAS. VST doesn’t seem to need a generated manifest, but RTAS does.

Sean Costello


#10

Yes, good request - if I don’t do it soon, please remind me![/quote]

Hi! I’m a friendly reminder!

In an ideal world, the manifest thing would be properly dealt with when building RTAS. VST doesn’t seem to need a generated manifest, but RTAS does.

[/quote]

Just a quick ping: does the Introjucer currently generate a manifest for RTAS plugins? I just ran into this issue again tonight.

Sean


#11

Can’t remember whether it creates a manifest, TBH. If not, then I guess it should…


#12

I’m afraid it doesn’t (but I may not be up to date with the GIT tip)
Introjucer generates a manifest only in debug, not in release. A manifest is however needed if your plugin is compiled with dynamic linkage to the CRT (ie /MD or /MDd rather than /MT or /MTd)
RTAS plugin almost always have dynamic linkage to CRT (they actually recommend 3rd party developpers do it this way on their devblog), so you will need a manifest for them.
VST plugin generated by the jucer have static linkage to the CRT by default, but you could change that if you want. (Jules, maybe you wanna add a feature to the introjucer, that would allow the user to select which linkage to the CRT we want to use, static or dynamic, that would also handle these manifest thing ? Your call…)

Now, just in case somebody needs it :
[list]
[]to change the linkage to CRT :
Go to Project Properties / C/C++ / Code Generation / Runtime Library.
The options with “DLL” are for dynamic linkage, the options without are fo static linkage.[/
]
[] to generate the manifest :
Go to Project Properties / Linker / Manifest File / Generate Manifest[/
][/list]
The above is for Visual Studio 2008 - I hope this helps