# Can't get Juce v1.53.17 to build a Windows DLL **URL:** \ **Category:** Windows\ **Created:** [February 3, 2011, 1:01pm UTC](https://forum.juce.com/t/cant-get-juce-v1-53-17-to-build-a-windows-dll/6356 "2011-02-03T13:01:49Z")\ **Posts on this page:** 12\ **Page:** 1
**Author:** ![gbevin](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/gbevin/32/258_2.png) [@gbevin](https://forum.juce.com/u/gbevin)\ **Post date:** [February 3, 2011, 1:01pm UTC](https://forum.juce.com/t/cant-get-juce-v1-53-17-to-build-a-windows-dll/6356/1 "2011-02-03T13:01:49Z")
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 ```auto 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' ``` ---
**Author:** ![gbevin](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/gbevin/32/258_2.png) [@gbevin](https://forum.juce.com/u/gbevin)\ **Post date:** [February 3, 2011, 1:43pm UTC](https://forum.juce.com/t/cant-get-juce-v1-53-17-to-build-a-windows-dll/6356/2 "2011-02-03T13:43:37Z")
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: ```auto 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 -JUCE_API std::basic_ostream & JUCE_CALLTYPE operator<< (std::basic_ostream & stream, const String& stringToWrite) +std::basic_ostream & JUCE_CALLTYPE operator<< (std::basic_ostream & 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 ``` ---
**Author:** ![jules](https://avatars.discourse-cdn.com/v4/letter/j/41988e/32.png) [@jules](https://forum.juce.com/u/jules)\ **Post date:** [February 3, 2011, 5:05pm UTC](https://forum.juce.com/t/cant-get-juce-v1-53-17-to-build-a-windows-dll/6356/3 "2011-02-03T17:05:55Z")
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. ---
**Author:** ![gbevin](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/gbevin/32/258_2.png) [@gbevin](https://forum.juce.com/u/gbevin)\ **Post date:** [February 3, 2011, 11:24pm UTC](https://forum.juce.com/t/cant-get-juce-v1-53-17-to-build-a-windows-dll/6356/4 "2011-02-03T23:24:02Z")
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: ```auto #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. ---
**Author:** ![jules](https://avatars.discourse-cdn.com/v4/letter/j/41988e/32.png) [@jules](https://forum.juce.com/u/jules)\ **Post date:** [February 4, 2011, 10:25am UTC](https://forum.juce.com/t/cant-get-juce-v1-53-17-to-build-a-windows-dll/6356/5 "2011-02-04T10:25:04Z")
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 ` ---
**Author:** ![gbevin](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/gbevin/32/258_2.png) [@gbevin](https://forum.juce.com/u/gbevin)\ **Post date:** [February 6, 2011, 7:07pm UTC](https://forum.juce.com/t/cant-get-juce-v1-53-17-to-build-a-windows-dll/6356/6 "2011-02-06T19:07:45Z")
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] ---
**Author:** ![jules](https://avatars.discourse-cdn.com/v4/letter/j/41988e/32.png) [@jules](https://forum.juce.com/u/jules)\ **Post date:** [February 6, 2011, 7:47pm UTC](https://forum.juce.com/t/cant-get-juce-v1-53-17-to-build-a-windows-dll/6356/7 "2011-02-06T19:47:21Z")
Ah yes, so I guess it’d need to be: ```auto #if defined (JUCE_DLL) && ! JUCE_AMALGAMATED_TEMPLATE ``` ---
**Author:** ![gbevin](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/gbevin/32/258_2.png) [@gbevin](https://forum.juce.com/u/gbevin)\ **Post date:** [February 6, 2011, 8:17pm UTC](https://forum.juce.com/t/cant-get-juce-v1-53-17-to-build-a-windows-dll/6356/8 "2011-02-06T20:17:36Z")
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: ```auto ``` ---
**Author:** ![jules](https://avatars.discourse-cdn.com/v4/letter/j/41988e/32.png) [@jules](https://forum.juce.com/u/jules)\ **Post date:** [February 7, 2011, 9:35am UTC](https://forum.juce.com/t/cant-get-juce-v1-53-17-to-build-a-windows-dll/6356/9 "2011-02-07T09:35:23Z")
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? ---
**Author:** ![gbevin](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/gbevin/32/258_2.png) [@gbevin](https://forum.juce.com/u/gbevin)\ **Post date:** [February 7, 2011, 9:39am UTC](https://forum.juce.com/t/cant-get-juce-v1-53-17-to-build-a-windows-dll/6356/10 "2011-02-07T09:39:53Z")
> [@jules](#): > > 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. ---
**Author:** ![jules](https://avatars.discourse-cdn.com/v4/letter/j/41988e/32.png) [@jules](https://forum.juce.com/u/jules)\ **Post date:** [February 7, 2011, 10:02am UTC](https://forum.juce.com/t/cant-get-juce-v1-53-17-to-build-a-windows-dll/6356/11 "2011-02-07T10:02:08Z")
Ah, I see - sorry, I was misunderstanding the whole problem. Ok then, in that case I guess it needs to just be removed altogether! ---
**Author:** ![gbevin](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/gbevin/32/258_2.png) [@gbevin](https://forum.juce.com/u/gbevin)\ **Post date:** [February 7, 2011, 10:07am UTC](https://forum.juce.com/t/cant-get-juce-v1-53-17-to-build-a-windows-dll/6356/12 "2011-02-07T10:07:33Z")
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. > [@jules](#): > > Ah, I see - sorry, I was misunderstanding the whole problem. Ok then, in that case I guess it needs to just be removed altogether!