Kjetil Matheussen

I'm using mingw 10.0.0 distributed by mxe. Not a big deal though since the dirty patch works just fine.

Oh, and the errors were the same as Birch-san, just worded differently because I used gcc instead of clang.

What seems to have happened is that newer versions of mingw has defined a lot more constants (constants that were previously missing), and now there are name clashes because juce...

There's nothing wrong with cross-compiling. Cross-compiling should always be safe, unless there's bugs in the compiler. What you seem to warn about here is using gcc or clang to compile...

Sure, but the problem is mingw, not cross-compiling. On Tue, May 3, 2022 at 10:13 AM Tom Poole ***@***.***> wrote: > Cross-compiling should always be safe, unless there's bugs in...

I was in a meeting, so sorry for being too harsh. My point was that if there is a problem with slightly different vtable layout only when cross-compiling, then there...

Same problem here. And it's i686, mingw 32bit, only. And I'm not using lvvm/clang. @reuk https://github.com/juce-framework/JUCE/commit/f429647ae90a010550c453006f7f1170e74d5718 and https://github.com/juce-framework/JUCE/commit/640194c87857978c86fcc4f3a0a5f675e323435c didn't fix this.

I fixed it in my build with this crude patch: ``` kjetil@tt:~/radium/pluginhost$ git diff . diff --git a/pluginhost/JuceLibraryCode/modules/juce_core/native/juce_win32_ComSmartPtr.h b/pluginhost/JuceLibraryCode/modules/juce_core/native/juce_win32_ComSmartPtr.h index b1f4bcb97..edddc5c68 100644 --- a/pluginhost/JuceLibraryCode/modules/juce_core/native/juce_win32_ComSmartPtr.h +++ b/pluginhost/JuceLibraryCode/modules/juce_core/native/juce_win32_ComSmartPtr.h @@ -23,7 +23,7 @@...

(forget that last thing about the JUCE_32BIT macro. :-)

Thanks!