JUCE is an open-source cross-platform C++ application framework for desktop and mobile applications, including VST, VST3, AU, AUv3, LV2 and AAX audio plug-ins.
If you build a VST3 plugin (I built the example AudioPlugin from the CMake examples directory) on a 32 bit ARM based platform (Raspberry Pi 4 in my case running Raspbian Buster), the plugin bundle structure is incorrect. The bundle that gets built has the folder structure of plugin.vst3/Contents/i386-linux/plugin.so, however for 32 bit armv7 the correct structure is plugin.vst3/Contents/armv7l-linux/plugin.so according to the vst3 documentation (the armv7l part will vary a bit depending on the specific architecture). This problem also occurred when I cross-compiled with CMake from x86_64 to arm using CMake.
Note: The above information applies to building with CMake. If you build with the projucer ( I built the default basic plugin when you start a new plugin project using the projucer), the folder is still incorrect, but it is named x86_64 instead. I haven't used the projucer much so it's possible there is a setting or something I missed there that caused that problem.
The .so files themselves are correctly built for the arm platform, and running the file command on the so produces the correct output that it is a 32 bit arm library, so nothing is wrong with the plugins themselves, just the folder structure.
Currently in order to get the hosts (I have tested using the JUCE audio plugin host built for ARM as well as REAPER for ARM) to scan the plugin, you must manually change the folder name from i386-linux to armv7l-linux. When using the juce audio plugin host, when you try and scan a plugin with incorrect folder structure you hit an assertion at line 885 of juce_VST3PluginFormat.cpp:
// The plugin NEEDS to provide a factory to be able to be called a VST3!
// Most likely you are trying to load a 32-bit VST3 from a 64-bit host
// or vice versa.
jassert (factory != nullptr);
Once you change the folder name the plugin scans correctly and the editor can be loaded in the plugin host just fine.
Note: The above information applies to building with CMake. If you build with the projucer ( I built the default basic plugin when you start a new plugin project using the projucer), the folder is still incorrect, but it is named x86_64 instead. I haven't used the projucer much so it's possible there is a setting or something I missed there that caused that problem.
The .so files themselves are correctly built for the arm platform, and running the file command on the so produces the correct output that it is a 32 bit arm library, so nothing is wrong with the plugins themselves, just the folder structure.
Currently in order to get the hosts (I have tested using the JUCE audio plugin host built for ARM as well as REAPER for ARM) to scan the plugin, you must manually change the folder name from i386-linux to armv7l-linux. When using the juce audio plugin host, when you try and scan a plugin with incorrect folder structure you hit an assertion at line 885 of juce_VST3PluginFormat.cpp:
Once you change the folder name the plugin scans correctly and the editor can be loaded in the plugin host just fine.