Trouble building JUCE 1.52 DLL and other compiler issues

Windows
1

I’m running into some build problems when compiling JUCE as a DLL. Here’s a list of issues I ran into in no particular order:

[list]
-Unresolved external linking errors when building a JUCE demo app under MSVC or Borland. eg. Image::BitmapData, AudioFormatWriter::ThreadedWriter and some others. It seems __declspec(dllexport) doesn’t quite do the same thing as GCC’s __attribute(visibility). Nested classes do not get export visibility for the former. The unresolved errors all seem to be referring to nested classes that’s not visible from outside the JUCE DLL.

-Ambiguous new/delete overload under all compiler toolchains I tried: MSVC, Borland, Mingw-gcc4.5.2 when building JUCE demo. This seems related to this issue but the relevant headers contains a deprecated comment for the UseDebuggingOption. I’m not sure what the correct fix is but commenting out the following in juce.h seems to temporarily fix the issue:

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

While the cause is obvious the fix isn’t, at least not for me. The ambigity issue comes up because the above macro will nullify user derived classes to not have overloaded new and delete. If those classes multi-inherit from juce classes that do overload new/delete than this problem comes up.

-In juce_String.h MSVC does not like

template <class charT, class traits>
JUCE_API std::basic_ostream <charT, traits>& JUCE_CALLTYPE operator<< (std::basic_ostream <charT, traits>& stream, const String& stringToWrite)

when JUCE_API = __declspec(dllimport) and I can see why it complains. DLL importing a template function in this context is non-sensical. This problem does not come up for mingw-gcc because it uses __attribute(visibility) instead and JUCE_API defines to nothing for the client program. Mingw-gcc also complains with the same error had it used __declspec(dllimport) in the same fashion.
[/list]

One last note, when building JUCE as a DLL I have JUCE_DLL_BUILD=1 and JUCE_DLL=1 defined. For building the demo apps I have only JUCE_DLL=1 defined. Is this the proper setup? I was unable to find any mention of how this should be done in the docs when building and using JUCE as a DLL.

Are any of these known issues and how should they be fixed?

Thanks

2

There’s not much point asking this about 1.52 - I can’t spend any time looking at bugs unless they’re present in the very latest version…

3

I downloaded the latest tip and tried building this in mingw-gcc 4.5.2 as a dll and got several compile errors:

[code]G:\OSS\juce\src\io\network\juce_Socket.cpp:237:88: error: ‘getaddrinfo’ was not declared in this scope
G:\OSS\juce\src\io\network\juce_Socket.cpp:245:31: error: ‘freeaddrinfo’ was not declared in this scope
G:\OSS\juce\src\io\network\juce_Socket.cpp:255:31: error: ‘freeaddrinfo’ was not declared in this scope
G:\OSS\juce\src\io\network\juce_Socket.cpp:261:27: error: ‘freeaddrinfo’ was not declared in this scope

G:\OSS\juce\src\native\windows\juce_win32_NativeIncludes.h:260:61: error: expected primary-expression before ‘)’ token
G:\OSS\juce\src\native\windows\juce_win32_NativeIncludes.h:260:61: error: there are no arguments to ‘__uuidof’ that depend on a template parameter, so a declaration of ‘__uuidof’ must be available
G:\OSS\juce\src\native\windows\juce_win32_NativeIncludes.h:260:61: note: (if you use ‘-fpermissive’, G++ will accept your code, but allowing the use of an undeclared name is deprecated)

G:\OSS\juce\src\native\windows\juce_win32_Windowing.cpp:2456:38: error: ‘HIMC’ has not been declared[/code]

The command used to compile them follows this pattern:

4

It looks like #define WIN32_LEAN_AND_MEAN has something to do with the HIMC declare error:

[code]#define WIN32_LEAN_AND_MEAN 1
#include <windows.h>

int main()
{
HIMC h;
}
[/code]

will yield the compile errors:

G:\OSS\stabs_test\main.cpp:496:5: error: 'HIMC' was not declared in this scope G:\OSS\stabs_test\main.cpp:496:10: error: expected ';' before 'h'

5

The __uuidof error is there because mingw does not support the __uuidof operator usage. After searching this issue for a bit I found this older thread actually mentions this issue. How should it be resolved?

6

By not using MINGW.

Seriously, a few years ago I attempted to stay compatible with MINGW for a while, but it was such a piece of crap that I gave up on it. Do yourself a favour and download a free copy of Visual C++ instead.

7

Dear Jules,

I am new in the forum. I am starting to work with Juce. It seems really powerfull. I usually work with mingw and I am having the uuidof problem that is described in this post. I would like to continue working with mingw and use juce too. Do you know any method for compiling juce libraries without to have in to account the _uuidof macro. I installed juce + mingw properly in another computer with windows 7, however I cant use it in my computer. It has windows vista. Could you please help me?. Thank you.

8

There might be a way of hacking together some sort of macro-based uuidof that works in mingw, but I’ve no time to mess about trying to figure it out myself.

9

Thank you, Jules.