Correct. I had the same problem as "jpo" described earlier in the thread, where the linker couldn't find the various "__mingw_uuidof<...>" functions. However, jpo's solution didn't work for me.
I don't understand the implications of "stomp all over the compile'rs implementation when running on MSVC" though. Is this only an issue if I wanted to compile on MSVC? (I don't see any reason to do that as long as it compiles in mingw)
Also note that I didn't suggest that this patch should go upstream, it was only meant as a help for others who may struggle with the same problem.
By the way, I use Juce to host VST plugins (http://users.notam02.no/~kjetism/radium/). Can there be problems if I load vst juce plugins compiled with MSVC in Radium? (Sorry, I don't know what the uuid code does)
You realise that your change isn't a fix, it'll actually disable support for all the COM uuids, so any of the JUCE functionality that relies on it would just stop working..?
Heh, no, I didn't look that closely at the source.
(I basically now nothing)
But I guess that as long as everything appear to work, it's okay? I guess the chance of getting any surprises are slim? I'm only using Juce to host VST plugins (and soon AU plugins). Nothing else. The rest of the program uses Qt and various other libraries.
I patched juce to build with gcc 4.9.2/mingw TDM including windows media format SDK; it reads mp3s, wma and such without the built-in juce mp3 decoder nor quicktime. Mostly a lot of namespace-hoop-jumping so mingw's uuid macros don't create symbols under juce:: which is a tad invasive.
Some workaround structs that juce defines for mingw aren't actually needed, others had to be re-re-hacked, needs some cleaning up by someone who enjoys the c preprocessor (not me!).
I had also started fixing WASAPI but really only cared about the codecs.
