Problems trying to cross-compile JUCE v7 on Linux to Windows target

Hi everyone,

I have some issues cross-compiling a standalone JUCE v7.0.0 application to Windows from a Ubuntu docker container. If you have some ideas what I could try I’d be grateful for your help.

I tried the mingw-64 (x86-64-w64-mingw32-posix) as well as the llvm-mingw toolchain (x86_64-w64-mingw32-clang++) and I’m getting pretty much the same errors :

There seems to be a problem with the declaration of the _clearfp function in JUCE/modules/juce_audio_processors/format_types/juce_VSTPluginFormat.cpp on line 71. Im getting the following error:

[ 56%] Building CXX object CMakeFiles/LaboratoriumAudioServer.dir/JUCE/modules/juce_audio_processors/juce_audio_processors.cpp.obj
In file included from /build/JUCE/modules/juce_audio_processors/juce_audio_processors.cpp:205:
/build/JUCE/modules/juce_audio_processors/format_types/juce_VSTPluginFormat.cpp:71:18: error: functions that differ only in their return type cannot be overloaded
 extern "C" void _clearfp();
            ~~~~ ^
/llvm-mingw/x86_64-w64-mingw32/include/float.h:266:46: note: previous declaration is here
_CRTIMP unsigned int __cdecl __MINGW_NOTHROW _clearfp (void);   /* Clear the FPU status word */
        ~~~~~~~~~~~~                         ^

If I change the relevant line

 extern "C" void _clearfp();


 extern "C" unsigned int _clearfp();

I’m not getting that error anymore, but then there are some problems with included headers in JUCE/modules/juce_gui_basics/juce_gui_basics.cpp on line 65, namely the headers UIAutomation.h and Dxgi.h can not be found.

If I remove those includes, I’m getting numerous other errors, probably because symbols from those headers can not be found.

Is there a way to make the cross-compilation work, maybe with a different JUCE version?

Thanks very much for your help.

There were some improvements in this area recently. Please try the latest version of JUCE from the develop branch.

That said, cross-compiling is not officially supported, and we don’t test it at all, so it’s still not guaranteed to work.

Thanks very much for the tip reuk, that gets me somewhere! :slight_smile:

The app compiles using x86_64-w64-mingw32-g++-posix with JUCE on the develop branch (on commit 7b61bdfba).

I still had to use

extern "C" unsigned int _clearfp();

though, and explicitly disable JUCE_PLUGINHOST_LV2 (but I guess that makes sense for a Windows build).

The linker still fails however, and at this point I don’t exactly know why, but I’ll report back when I figure something out.

As for llvm-mingw / clang: That also compiles with the fixes above, but the linker cannot find the libatomic1 library.

I had a dig through my shell history, and it looks like the last time I tested this out, I was using the following CMake flags, where the llvm-mingw-20220323-ucrt-ubuntu-18.04-x86_64 folder is one of the pre-built releases from the project page.

"CMAKE_C_COMPILER": "$env{HOME}/development/llvm-mingw-20220323-ucrt-ubuntu-18.04-x86_64/bin/x86_64-w64-mingw32-clang",
"CMAKE_CXX_COMPILER": "$env{HOME}/development/llvm-mingw-20220323-ucrt-ubuntu-18.04-x86_64/bin/x86_64-w64-mingw32-clang++",
"CMAKE_CXX_FLAGS": "-static",
"CMAKE_FIND_ROOT_PATH": "$env{HOME}/development/llvm-mingw-20220323-ucrt-ubuntu-18.04-x86_64/x86-64-w64-mingw32"

These flags allow me to successfully build the AudioPluginHost, including LV2 hosting functionality, and without making any changes to JUCE. Getting VST2 hosting to work does require changing/removing the _clearfp and _fpreset declarations, as you discovered.

Alternatively, Fedora provides a mingw64-filesystem package that includes mingw64-cmake, a wrapper around CMake that automatically sets up the build environment for cross-compiling. By default, this will use GCC rather than Clang. The following command produced a working build tree:

1 Like