Site navigation

PT8 + vs2010: missing libs

The Projucer
#1

Hey guys,

No idea if it RUNS yet, but in order to compile RTAS plugins with PT8 in vs2010 these libraries seem to be missing:

DSPManager.lib
DSPManagerClientLib.lib
RTASClientLib.lib

(PT PluginLib was also built with vs2010)

I.e. if I dont add them manually to the project I get a lot of unresolved externals, if I add them at least it compiles…

  • bram
#2

Ok… now I’m a bit confused about how it would have worked without those in older versions of VS.

There’s actually no need to modify the project - I normally add the libs using #pragmas, so it should be easy enough just to add these to the list of other PT libs, in juce_RTAS_Wrapper.cpp, line 110:

#pragma comment(lib, PT_LIB_PATH "DAE.lib") #pragma comment(lib, PT_LIB_PATH "DigiExt.lib") #pragma comment(lib, PT_LIB_PATH "DSI.lib") #pragma comment(lib, PT_LIB_PATH "PluginLib.lib") #pragma comment(lib, PT_LIB_PATH "DSPManager.lib") #pragma comment(lib, PT_LIB_PATH "DSPManagerClientLib.lib") #pragma comment(lib, PT_LIB_PATH "RTASClientLib.lib")

#3

So does this mean you will (or have already - knowing you) add these?

I’m ALSO rather confused about this, FYI…

  • bram
#4

I’ll add them… Is it perhaps a difference between versions of the PT SDK? E.g. were they not needed in the v8 SDK, but are needed in v9?

#5

Nope…

PT 8 SDK built in vs2008 + plugin built in vs2008 = builds just fine
PT 8 SDK built in vs2010 + plugin built in vs2010 = unresolved externals galore

  • bram
#6

FYI: just tested the plugin and it works fine in PT9. It’s a basic test, but… This does mean that it’s definitely possible to build the PT8 library and RTAS plugins in vs2010 (I saw that you recommended using vs2005 a few years back).
That’s good news because it means we can build VST32+vst64+rtas32 in one environment.
For AAX on 'doze seems a bit early, right?

  • bram
#7

Strange…

Ok, well something like this might be the answer:

[code] #pragma comment(lib, PT_LIB_PATH “DAE.lib”)
#pragma comment(lib, PT_LIB_PATH “DigiExt.lib”)
#pragma comment(lib, PT_LIB_PATH “DSI.lib”)
#pragma comment(lib, PT_LIB_PATH “PluginLib.lib”)

#if _MSC_VER >= 1500
#pragma comment(lib, PT_LIB_PATH “DSPManager.lib”)
#pragma comment(lib, PT_LIB_PATH “DSPManagerClientLib.lib”)
#pragma comment(lib, PT_LIB_PATH “RTASClientLib.lib”)
#endif
[/code]

#8

It’s getting weirder by the second… I tried that fix and sometimes I get things to work, sometimes I don’t. It’s VERY weird.
I’m investigating some more.
With the pragmas I never got it to build, but with the additional includes I did.
I did see that there was this rather interesting thing you wrote here:

 #if JUCE_DEBUGxxx // (the debug lib in the 8.0 SDK fails to link, so we'll stick to the release one...)
  #define PT_LIB_PATH  JucePlugin_WinBag_path "\\Debug\\lib\\"
 #else
  #define PT_LIB_PATH  JucePlugin_WinBag_path "\\Release\\lib\\"
 #endif

Notice the “xxx”! In vs2010 this could lead to trouble as you are using release libs with a debug build…

  • bram
#9

Never mind Jules, don;t add that change, we’re going back to 2008 for RTAS. I tried just about everything in 2010 and sometimes (seemingly random!) it works, but doing another clean build it fails. That’s pretty scary, so no go.

One of the problems is that PluginLib defines _HAS_ITERATOR_DEBUGGING=0; even in Debug mode which makes vs2010 throw up lot’s of errors about iterator debugging. Removing the define in PluginLibrary skips those but then there are sudenly unresolved externals in RTASClientLib.lib. It’s all a bit of a mystery.

  • bram
#10

Wow, that is truly scary.

I’m afraid that the RTAS libs have always been very rather precarious in terms of the exact version of VS that they work with. Fingers crossed that the AAX SDK will be less fussy!