[Bug]: JUCE 6.1.5 fails to compile with 20220209 release of llvm-mingw

[Birch-san]

Detailed steps on how to reproduce the bug

Containerised repro using JUCE audio plugin example:

git clone https://github.com/Birch-san/juce-repro.git
cd juce-repro
docker build .

juce_win32_ComInterfaces.h attempts to define UIA_ constants. These clash with the macros defined in MinGW's uiautomationclient.h.

When we compile with llvm-mingw 20220209, we get the following error:

In file included from /linux_native/include/JUCE-6.1.5/modules/juce_gui_basics/juce_gui_basics.cpp:309:
/linux_native/include/JUCE-6.1.5/modules/juce_gui_basics/native/accessibility/juce_win32_ComInterfaces.h:123:12: error: expected unqualified-id
const long UIA_InvokePatternId = 10000;
           ^
/opt/llvm-mingw/x86_64-w64-mingw32/include/uiautomationclient.h:34:30: note: expanded from macro 'UIA_InvokePatternId'
#define UIA_InvokePatternId (10000)

JUCE tries to declare a constant:

const long UIA_InvokePatternId = 10000;

But the token UIA_InvokePatternId already exists as a MinGW macro, and expands to (10000), making the statement:

const long (10000) = 10000;

This compiles fine in llvm-mingw 20211002. Perhaps the MinGW uiautomationclient.h header was different back then?

I am currently working around the problem by telling MinGW not to define any UIA_ macros, and manually supplying the macros upon which JUCE depends.

What is the expected behaviour?

Successful compilation. JUCE should not declare any constants whose names would clash with macros provided by MinGW.

Operating systems

Linux

What versions of the operating systems?

Ubuntu 22.04 cross-compiling for Windows 7 x86_64

Architectures

x86_64

Stacktrace

Full stack here:
https://gist.github.com/Birch-san/0364f650a70505ce8c4b1859eab19b0e

In file included from /linux_native/include/JUCE-6.1.5/modules/juce_gui_basics/juce_gui_basics.cpp:309:
/linux_native/include/JUCE-6.1.5/modules/juce_gui_basics/native/accessibility/juce_win32_ComInterfaces.h:123:12: error: expected unqualified-id
const long UIA_InvokePatternId = 10000;
           ^
/opt/llvm-mingw/x86_64-w64-mingw32/include/uiautomationclient.h:34:30: note: expanded from macro 'UIA_InvokePatternId'
#define UIA_InvokePatternId (10000)

Plug-in formats (if applicable)

No response

Plug-in host applications (DAWs) (if applicable)

No response

Testing on the develop branch

I have not tested against the develop branch

Code of Conduct

• [X] I agree to follow the Code of Conduct

[kmatheussen]

Same problem here. Doesn't compile with mingw. I'm not using llvm/clang to compile with though, but maybe it's caused by just having installed llvm? Anway, I just made a dirty patch for JUCE to fix this: mingw_compilation_fix.diff.gz

[reuk]

Which MinGW are you using, on which platform, and what errors are you seeing?

We test the version of MinGW bundled with CodeBlocks (based on GCC 8.1) in our CI. This version should definitely work, and I'd expect newer versions to work too.

We don't regularly test the cross-compiling scenario (this isn't officially supported) so this may not work out-of-the-box.

[kmatheussen]

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

[kmatheussen]

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

[kmatheussen]

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 also defines these constants because they were missing in earlier versions of mingw.

[Birch-san]

We don't regularly test the cross-compiling scenario (this isn't officially supported) so this may not work out-of-the-box.

@reuk if I were to contribute to JUCE's CI, an example of "cross-compiling JUCE's audio plugin example via CMake + LLVM/MinGW on Linux": would JUCE be willing to support it (i.e. make sure the build continues to pass)?

[tpoole]

We know how to put a cross-compiling example together, but that's no guarantee that you will have a working plug-in. You can run into really nasty problems, like slightly different vtable layouts expected by the host and plug-in, which result in extremely confusing run-time crashes. The plug-in SDKs themselves also provide no guarantees about being safe to cross-compile, so we cannot provide that guarantee either.

We can try to keep up with changes in mingw, but cross-compiling isn't something we want to encourage.

[kmatheussen]

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 windows plugins with.

On Tue, May 3, 2022 at 9:44 AM Tom Poole @.***> wrote:

We know how to put a cross-compiling example together, but that's no guarantee that you will have a working plug-in. You can run into really nasty problems, like slightly different vtable layouts expected by the host and plug-in, which result in extremely confusing run-time crashes. The plug-in SDKs themselves also provide no guarantees about being safe to cross-compile, so we cannot provide that guarantee either.

We can try to keep up with changes in mingw, but cross-compiling isn't something we want to encourage.

— Reply to this email directly, view it on GitHub https://github.com/juce-framework/JUCE/issues/1028#issuecomment-1115821701, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIX3J53DQMCF2ZKF6EQ4BLVIDKMBANCNFSM5OJ4UYXA . You are receiving this because you commented.Message ID: @.***>

[tpoole]

Cross-compiling should always be safe, unless there's bugs in the compiler.

We have a rich history of things not working as expected when people have used mingw to compile Windows plug-ins from Linux. When things go wrong the response from plug-in SDK publishers is that they don't support that use case, and we are unwilling to make extensive modifications to our plug-in SDK dependencies that then need to be maintained on SDK version updates.

Maybe you have had much better fortune, but we have been burnt badly. Are you able to create a fully working, signed, AAX plug-in? That tends to be the most sensitive process.

[kmatheussen]

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 the compiler.

We have a rich history of things not working as expected when people have used mingw to compile Windows plug-ins from Linux. When things go wrong the response from plug-in SDK publishers is that they don't support that use case, and we are unwilling to make extensive modifications to our plug-in SDK dependencies that then need to be maintained on SDK version updates.

Maybe you have had much better fortune, but we have been burnt badly. Are you able to create a fully working, signed, AAX plug-in? That tends to be the most sensitive process.

— Reply to this email directly, view it on GitHub https://github.com/juce-framework/JUCE/issues/1028#issuecomment-1115841506, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIX3JYBUMHCZ7NQFVCDCHDVIDNZTANCNFSM5OJ4UYXA . You are receiving this because you commented.Message ID: @.***>

[kmatheussen]

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 must be a bug in the compiler. Cross-compiling should not cause that problem.

On Tue, May 3, 2022 at 10:30 AM Kjetil Matheussen @.***> wrote:

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 the compiler.

We have a rich history of things not working as expected when people have used mingw to compile Windows plug-ins from Linux. When things go wrong the response from plug-in SDK publishers is that they don't support that use case, and we are unwilling to make extensive modifications to our plug-in SDK dependencies that then need to be maintained on SDK version updates.

Maybe you have had much better fortune, but we have been burnt badly. Are you able to create a fully working, signed, AAX plug-in? That tends to be the most sensitive process.

— Reply to this email directly, view it on GitHub https://github.com/juce-framework/JUCE/issues/1028#issuecomment-1115841506, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIX3JYBUMHCZ7NQFVCDCHDVIDNZTANCNFSM5OJ4UYXA . You are receiving this because you commented.Message ID: @.***>

[mangobrain]

https://github.com/juce-framework/JUCE/pull/1073 tries to address this. If it breaks other toolchains then things could be normalised the other way round (i.e. instead of removing the named constants and making everything a macro, make everything a named constant, and explicitly #undefine all the macros from the MinGW header).

Apparently I can't actually link the pull request directly to this issue, because

• "If you want to link a pull request to an issue using a keyword, the PR must be on the default branch."
• "All work should be based on our develop branch."
• :facepalm:

[reuk]

Thanks, JUCE should now build with the llvm-mingw headers: https://github.com/juce-framework/JUCE/commit/045214c986c74b2427f3aab2a5d2bfab2570be85