We’ve just upgraded Juce to a GIT checkout from a few days ago (v1.53.17) and got everything to build on MacOSX with a bit of tweaking for changed APIs. However, now I’m trying to build a DLL with the same build infrastructure as we used on a previous Juce version (v1.52.78) but I can’t get it to work (using VS2010). I’m passing the compiler the following flags specifically for Juce: -DWINDOWS=1 -DNDEBUG=1 -DJUCE_DLL_BUILD -DJUCE_DLL.
I’m getting errors like what I pasted below.
Does anyone have an idea? It seems to be related to juce_UseDebuggingNewOperator being replaced by JUCE_DECLARE_NON_COPYABLE_WITH_LEAK_DETECTOR.
Thanks,
Geert
c:\cygwin\home\geert\eigend\lib_juce\juce_amalgamated.cpp(34066) : error C2385: ambiguous access of 'delete'
could be the 'delete' in base 'juce::AudioPluginInstance'
or could be the 'delete' in base 'juce::AsyncUpdater'
This diagnostic occurred in the compiler generated function 'void *juce::VSTPluginInstance::__delDtor(unsigned int)'
c:\cygwin\home\geert\eigend\lib_juce\juce_amalgamated.cpp(35038) : error C2385: ambiguous access of 'new'
could be the 'new' in base 'juce::Component'
or could be the 'new' in base 'juce::ComponentMovementWatcher'
c:\cygwin\home\geert\eigend\lib_juce\juce_amalgamated.cpp(35038) : error C2385: ambiguous access of 'delete'
could be the 'delete' in base 'juce::Component'
or could be the 'delete' in base 'juce::ComponentMovementWatcher'
c:\cygwin\home\geert\eigend\lib_juce\juce_amalgamated.cpp(35980) : error C2385: ambiguous access of 'new'
could be the 'new' in base 'juce::AudioPluginInstance'
or could be the 'new' in base 'juce::AsyncUpdater'
c:\cygwin\home\geert\eigend\lib_juce\juce_amalgamated.cpp(35980) : error C2385: ambiguous access of 'delete'
could be the 'delete' in base 'juce::AudioPluginInstance'
or could be the 'delete' in base 'juce::AsyncUpdater'
c:\cygwin\home\geert\eigend\lib_juce\juce_amalgamated.cpp(39753) : error C2385: ambiguous access of 'new'
could be the 'new' in base 'juce::Thread'
or could be the 'new' in base 'juce::AsyncUpdater'
c:\cygwin\home\geert\eigend\lib_juce\juce_amalgamated.cpp(39753) : error C2385: ambiguous access of 'delete'
could be the 'delete' in base 'juce::Thread'
or could be the 'delete' in base 'juce::AsyncUpdater'
c:\cygwin\home\geert\eigend\lib_juce\juce_amalgamated.cpp(59333) : error C2385: ambiguous access of 'new'
could be the 'new' in base 'juce::Component'
or could be the 'new' in base 'juce::AsyncUpdater'
c:\cygwin\home\geert\eigend\lib_juce\juce_amalgamated.cpp(59333) : error C2385: ambiguous access of 'delete'
could be the 'delete' in base 'juce::Component'
or could be the 'delete' in base 'juce::AsyncUpdater'
c:\cygwin\home\geert\eigend\lib_juce\juce_amalgamated.cpp(59926) : error C2385: ambiguous access of 'new'
could be the 'new' in base 'juce::TreeViewItem'
or could be the 'new' in base 'juce::AsyncUpdater'
c:\cygwin\home\geert\eigend\lib_juce\juce_amalgamated.cpp(59926) : error C2385: ambiguous access of 'delete'
could be the 'delete' in base 'juce::TreeViewItem'
or could be the 'delete' in base 'juce::AsyncUpdater'
c:\cygwin\home\geert\eigend\lib_juce\juce_amalgamated.cpp(60023) : error C2385: ambiguous access of 'new'
could be the 'new' in base 'juce::TreeViewItem'
or could be the 'new' in base 'juce::AsyncUpdater'
c:\cygwin\home\geert\eigend\lib_juce\juce_amalgamated.cpp(60023) : error C2385: ambiguous access of 'delete'
could be the 'delete' in base 'juce::TreeViewItem'
or could be the 'delete' in base 'juce::AsyncUpdater'
Thanks. Sorry that I haven’t kept on top of the DLL build, it’s a real pain to try to maintain it as well as everything else.
You’d get the ambiguous new problem if a class derives from multiple base classes which have set the JUCE_LEAK_DETECTOR, but doesn’t itself also contain a JUCE_LEAK_DETECTOR statement. (Basically, for the DLL I’ve just hijacked the JUCE_LEAK_DETECTOR macro to override the new/delete operators to make the allocation work across DLL boundaries). But of course, not checking the DLL build very often, I’m likely to miss the places where I’ve forgotten to add the macro to classes that need it.
It’s difficult to see from your listing which classes are at fault, but if you let me know, I’ll add the leak detector statement to them.
That makes Juce compile successfully as a DLL but doesn’t work for other code the includes juce_amalgamated.h with JUCE_DLL set. This is needed for the __declspec (dllimport) stuff to work. Since JUCE_AMALGAMATED_TEMPLATE is only set in juce_amalgamated.cpp, the JUCE_LEAK_DETECTOR macro becomes a no-op for classes including juce_amalgamated.h.
[quote=“jules”]aha! Ok, thanks, I guess that should be:
#if defined (JUCE_DLL) && ! (JUCE_AMALGAMATED_TEMPLATE || defined (JUCE_DLL_BUILD))
#undef JUCE_LEAK_DETECTOR
#define JUCE_LEAK_DETECTOR(OwnerClass)
#endif
[/quote]
That would still create the same problem, no? For files including juce_amalgamated.h with JUCE_DLL set for the dllimport stuff, JUCE_AMALGAMATED_TEMPLATE wouldn’t be set since juce_amalgamated.cpp isn’t compiled. Maybe JUCE_AMALGAMATED_TEMPLATE should be set to 1 right at the beginning of juce_amalgamated.h?
[quote=“jules”]Ah yes, so I guess it’d need to be:
Ok… I’m confused by this now… Looking again, the line we’re talking about happens after all of the juce headers have already been included, so will have no effect on any juce classes - the macro is just being nullified to prevent problems if you’ve used JUCE_LEAK_DETECTOR in your own code. So I don’t understand how changing it could make a difference to the linkage of the juce classes?
Well, if you’re using it in your own code, nullifying it in the juce_amalgamated header causes the JUCE_LEAK_DETECTOR to have no effect in your own code, resulting in those ambiguous ‘new’ and ‘delete’ compilation errors.
Indeed, I don’t see a need to keep it in the amalgamated files at all. I assumed that the JUCE_AMALGAMATED_TEMPLATE define was to indicate sections of code that use have no effect in amalgamated mode. However, if that’s defined in the implementation instead of at the beginning of the header, it doesn’t have its full effect.