Can't get Juce v1.53.17 to build a Windows DLL


#1

Hi,

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'

#2

Went back to v1.52.110, which is the last release version, and the same happens there.

Btw, I had to make two changes for it to build:

diff --git a/lib_juce/juce_amalgamated.h b/lib_juce/juce_amalgamated.h
index 0c42eba..efbd81b 100755
--- a/lib_juce/juce_amalgamated.h
+++ b/lib_juce/juce_amalgamated.h
@@ -2805,7 +2805,7 @@ JUCE_API bool JUCE_CALLTYPE operator<= (const String& string1, const String& str
 	This is very handy for writing strings to std::cout, std::cerr, etc.
 */
 template <class charT, class traits>
-JUCE_API std::basic_ostream <charT, traits>& JUCE_CALLTYPE operator<< (std::basic_ostream <charT, traits>& stream, const String& stringToWrite)
+std::basic_ostream <charT, traits>& JUCE_CALLTYPE operator<< (std::basic_ostream <charT, traits>& stream, const String& stringToWrite)
 {
 	return stream << stringToWrite.toUTF8();
 }
@@ -63345,7 +63345,7 @@ private:
 #endif
 
 #ifdef JUCE_DLL
-  #undef JUCE_LEAK_DETECTOR(OwnerClass)
+  #undef JUCE_LEAK_DETECTOR
   #define JUCE_LEAK_DETECTOR(OwnerClass)
 #endif

#3

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.


#4

I just now figured it out. It’s a problem with the amalgamation.

This section from juce.h is at the end of the juce_amalgamated.h file:

#ifdef JUCE_DLL
  #undef JUCE_LEAK_DETECTOR(OwnerClass)
  #define JUCE_LEAK_DETECTOR(OwnerClass)
#endif

It basically nullifies any defines for JUCE_LEAK_DETECTOR in the amalgamated version.


#5

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


#6

Hi Jules,

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]


#7

Ah yes, so I guess it’d need to be:


#8

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:


#9

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?


#10

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.


#11

Ah, I see - sorry, I was misunderstanding the whole problem. Ok then, in that case I guess it needs to just be removed altogether!


#12

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.