Maybe new Jucer bugs, maybe not


#1

…but worth bringing up:

I was building a Windows RTAS from a project generated by the new Jucer, and had a few issues come up:

  • Lot of LNK2001 errors. This was due to juce_amalgamated.cpp not being included within the project. A quick search of the forum turned up the solution (i.e. include the said .cpp file), but I’m wondering if the new Jucer should include this in the RTAS projects by default. The issue doesn’t come up with VST for me.

  • After the above change, the project compiled and ran, but when I opened up Pro Tools 8, my plugin generated an error saying that I didn’t have msvcm90.dll, and that I needed to install that. A bit of Googling revealed that my VisualStudio project didn’t have Manifest Embedding turned on. Not even sure what that is, but turning it on (by going into Configuration Properties->Linker->Manifest File, and setting “Generate Manifest” to Yes) seems to have resolved the issue. I have no idea if the Jucer can put set this correctly in the generated project, but if it could, that would be just keen.

Thanks,

Sean Costello


#2

Whether or not the project contains juce_amalgamated.cpp is an option that has nothing to do with the RTAS stuff… it just sounds like you had “don’t like to juce” selected under the “juce linkage method” setting?


#3

[quote]- After the above change, the project compiled and ran, but when I opened up Pro Tools 8, my plugin generated an error saying that I didn’t have msvcm90.dll, and that I needed to install that. A bit of Googling revealed that my VisualStudio project didn’t have Manifest Embedding turned on. Not even sure what that is, but turning it on (by going into Configuration Properties->Linker->Manifest File, and setting “Generate Manifest” to Yes) seems to have resolved the issue. I have no idea if the Jucer can put set this correctly in the generated project, but if it could, that would be just keen.
[/quote]

Have you tried this more recently? I was having a lot of trouble with this exact same issue yesterday - but manifest embedding definately seems to be turned on?

Cheers
Dave


#4

Ahhh, there are TWO manifest file generation options that need to be set. Sorted now - you have to set Generate Manifest to Yes under the linker manifest file options, not in the Manifest Tool options (which is already set in the Jucer project).

Two more issues though :-

  1. I can’t make a debug build from the project, linking fails as follows:-

1>Linking…
1>PluginLib.lib(DOA_IUnknown.obj) : warning LNK4006: _IID_IUnknown already defined in uuid.lib(unknwn_i.obj); second definition ignored
1> Creating library .\Debug\Juce Plugin Test.lib and object .\Debug\Juce Plugin Test.exp
1>LINK : warning LNK4199: /DELAYLOAD:PluginLib.dll ignored; no imports found from PluginLib.dll
1>PluginLib.lib(CSet.obj) : error LNK2019: unresolved external symbol “__declspec(dllimport) public: __thiscall std::_Container_base::_Container_base(void)” (_imp??0_Container_base@std@@QAE@XZ) referenced in function “public: __thiscall std::_Tmap_traits<void *,class CBaseSetElement *,class CBaseSetMap::KeyCompare,class std::allocator<struct std::pair<void * const,class CBaseSetElement *> >,0>::_Tmap_traits<void *,class CBaseSetElement *,class CBaseSetMap::KeyCompare,class std::allocator<struct std::pair<void * const,class CBaseSetElement *> >,0>(class CBaseSetMap::KeyCompare)” (??0?$_Tmap_traits@PAXPAVCBaseSetElement@@VKeyCompare@CBaseSetMap@@V?$allocator@U?$pair@QAXPAVCBaseSetElement@@@std@@@std@@$0A@@std@@QAE@VKeyCompare@CBaseSetMap@@@Z)
1>PluginLib.lib(CObjectMap.obj) : error LNK2001: unresolved external symbol “__declspec(dllimport) public: __thiscall std::_Container_base::_Container_base(void)” (_imp??0_Container_base@std@@QAE@XZ)
1>PluginLib.lib(CPlugInStreams.obj) : error LNK2001: unresolved external symbol “__declspec(dllimport) public: __thiscall std::_Container_base::_Container_base(void)” (_imp??0_Container_base@std@@QAE@XZ)

There’s no problem with my PluginLib compilation that I can find, it was a straight-out-of-the-box install of the PT80 SDK followed by a straight-out-of-the-box compile. PT sample plugins compile fine.

  1. In my Jucer options I specified I wanted a VST and RTAS build, but I only get the RTAS .dpm - is it not possible to have a hybrid VST/RTAS build on Windows as it is on Mac?

Cheers
Dave


#5

I’m a bit mystified by the link error - it looks like it’s trying to link the wrong version of the dll or something…?

Yep, the same file can be renamed as a .dll and it should work as a VST.


#6

I did try this before and it failed (presumably because the manifest file wasn’t being generated and embedded). I just tried again and it worked.

Might be a good idea to have a post-built step that does that automatically, then the Windows project will behave more similarly to the Mac project.

Cheers
Dave


#7

The PluginLib I built using the PT_80_SDK is a static library - where does the DLL come into it?


#8

Sorry, I meant ‘lib’ of course.


#9

Ah :slight_smile:

There are still two things that are confusing me though. PluginLib, DAE, DSPmanager - they’re all static libs. So why the “Delay Loaded DLLs” in the linker settings specifying them as DLLs?

Also, I looked back at my own RTAS projects and I don’t even link statically to anything. This is because all the Digi code the plugins need is wrapped and included into the project (as you know because, well, you wrote my RTAS wrapper :smiley: ). In your projects its the same, all the Digi code the plugins need are wrapped via juce_RTAS_DigiCode1.cpp etc.

So it seems most likely to me that perhaps you’ve just not wrapped one particular Digi file the build needs, and all that Delay Loaded DLL stuff is irrelevent?


#10

No… it does need to link to those Digi libs, but they aren’t specified in the project, there are pragmas inside juce_RTAS_Wrapper.cpp that add them to the link stage.


#11

Yeah, I did eventually find them (a strange way of doing it if you don’t mind me saying). I had a fiddle about but after a while trying to resolve the dependencies made my head hurt, so I solved my problem by using the Release version of PluginLib.lib for debug builds. This is the process I had to go through to get this far, maybe this isn’t a typical experience?

  1. Run the Jucer on Mac because the Windows version required two updates to get it to work and seems to mess up the paths anyway
  2. Copy the resulting files over to the PC, try to compile. Get 105 warnings on the release build but it doesn’t run
  3. Eventually figure out the linker manifest settings are wrong, fix them and get an RTAS build that runs in PT8LE
  4. Hunt about for the VST version, its not there…
  5. Figure out I need to add a post-built step to copy and rename the RTAS .dpm file to .dll, now I got combined release builds (with 107 warnings still)
  6. Debug build fails with mysterious linker errors. Spend a day on it but getting nowhere
  7. Eventually figure out that linker includes are inline via #pragmas, change the debug build to link against the release version of PluginLib.lib
  8. Finally get all four builds (with floods of warnings)
  9. …and then the VST builds don’t work in Nuendo 5, VST host or anything else I tested in

So…you working mostly on mac these days Jules? :evil: :mrgreen:


#12

:oops:

Actually, its just the debug builds - the ones I bodged to make them compile. Neither the VST or RTAS debug builds actually work, the unbodged release builds are fine.

So after two days of bashing at it I still have not been able to make a fully working combined VST/RTAS project with the Jucer :cry:

Cheers
Dave


#13

Ok, I’m on the case. I think these problems must be due to changes in the 8.0 SDK, as I was still using the 7.3 one until just recently. I’ve reproduced the link errors, will figure it out and check in an update shortly…


#14

All my existing code is for the 7.3 SDK also, and 7.11 before that. I seem to remember only minor changes between the two, 8 looks like a bit more of a leap.


#15

Still not working with latest tip (1.53.41) I’m afraid. I see the change in the RTAS wrapper to link against the release version of the lib and although that lets it compile, the resulting RTAS and VST debug builds do not actually work.

…and the linker settings in the Release build for manifest embedding are still wrong too. At least the spew of warnings has improved dramatically :smiley:

Cheers
Dave


#16

Yeah, I tidied up the obvious stuff, but am a bit baffled about why it’d not work…


#17

It’s not good if we’re both baffled :?


#18

Any follow-up on this? I’ve been sweating over some PHP recently and haven’t visited the world of JUCE…


#19

Sorry, I’ve been sweating over android stuff…


#20

[quote=“muonsoftware”][quote]- After the above change, the project compiled and ran, but when I opened up Pro Tools 8, my plugin generated an error saying that I didn’t have msvcm90.dll, and that I needed to install that. A bit of Googling revealed that my VisualStudio project didn’t have Manifest Embedding turned on. Not even sure what that is, but turning it on (by going into Configuration Properties->Linker->Manifest File, and setting “Generate Manifest” to Yes) seems to have resolved the issue. I have no idea if the Jucer can put set this correctly in the generated project, but if it could, that would be just keen.
[/quote]

Have you tried this more recently? I was having a lot of trouble with this exact same issue yesterday - but manifest embedding definately seems to be turned on?

Cheers
Dave[/quote]

I haven’t done any Windows builds in awhile. I’m porting over a new plugin to Windows starting today, so I’ll keep you posted on the progress.

I remember that I was never able to get a Debug build of the RTAS plugins working. I start with VST, then move over to RTAS once that is working well.

Also, I have found that building polymorphic Juce plugins doesn’t work for VST+RTAS, as some VST hosts have problems loading the resulting VST. I’m not sure why. Creating two separate projects solved the issue for me.

Sean Costello