FL studio fails to load Juce Plugin

I’m not sure what the problem is. Is the installation supposed to copy over DLL files? Or should these not be statically linked into the VST3 file?

Build Log:

====================[ Build | test_plugin_VST3 | Debug ]=====================
C:\Users\Tobi\AppData\Local\JetBrains\Toolbox\apps\CLion\ch-0\213.5744.254\bin\cmake\win\bin\cmake.exe --build C:\Users\Tobi\Documents\test-plugin\cmake-build-debug --target test_plugin_VST3
[0/2] Re-checking globbed directories...
[1/2] Re-running CMake...
...
[35/41] Building CXX object CMakeFiles\test_plugin.dir\_deps\juce-src\modules\juce_gui_basics\juce_gui_basics.cpp.obj
[36/41] Building CXX object CMakeFiles\test_plugin.dir\_deps\juce-src\modules\juce_audio_devices\juce_audio_devices.cpp.obj
[37/41] Building CXX object CMakeFiles\test_plugin.dir\_deps\juce-src\modules\juce_core\juce_core.cpp.obj
[38/41] Building CXX object CMakeFiles\test_plugin.dir\_deps\juce-src\modules\juce_audio_formats\juce_audio_formats.cpp.obj
[39/41] Linking CXX static library test_plugin_artefacts\Debug\test_SharedCode.lib
[40/41] Building CXX object CMakeFiles\test_plugin_VST3.dir\_deps\juce-src\modules\juce_audio_plugin_client\juce_audio_plugin_client_VST3.cpp.obj
[41/41] Linking CXX shared module test_plugin_artefacts\Debug\VST3\test.vst3\Contents\x86_64-win\test.vst3
-- Installing: C:\Program Files\Common Files/VST3/test.vst3
-- Installing: C:\Program Files\Common Files/VST3/test.vst3/Contents
-- Installing: C:\Program Files\Common Files/VST3/test.vst3/Contents/x86_64-win
-- Installing: C:\Program Files\Common Files/VST3/test.vst3/Contents/x86_64-win/abseil_dll.dll
-- Installing: C:\Program Files\Common Files/VST3/test.vst3/Contents/x86_64-win/cares.dll
-- Installing: C:\Program Files\Common Files/VST3/test.vst3/Contents/x86_64-win/libcrypto-1_1-x64.dll
-- Installing: C:\Program Files\Common Files/VST3/test.vst3/Contents/x86_64-win/libprotobufd.dll
-- Installing: C:\Program Files\Common Files/VST3/test.vst3/Contents/x86_64-win/libssl-1_1-x64.dll
-- Installing: C:\Program Files\Common Files/VST3/test.vst3/Contents/x86_64-win/re2.dll
-- Installing: C:\Program Files\Common Files/VST3/test.vst3/Contents/x86_64-win/test.ilk
-- Installing: C:\Program Files\Common Files/VST3/test.vst3/Contents/x86_64-win/test.vst3
-- Installing: C:\Program Files\Common Files/VST3/test.vst3/Contents/x86_64-win/zlibd1.dll

Build finished

It’s probably a good idea to test the scanning/loading process in a host you can debug easily, such as the AudioPluginHost.

I’d also recommend against using .dll dependencies in a plugin if at all possible. Prefer static linking in plugin builds. IIRC the library search procedure on Windows won’t look for additional libraries next to the plugin dll, so the dependencies won’t be found properly. You might have more luck by installing the libraries to a known location and then loading them manually from that location, but there are still drawbacks with this approach. If a DLL with the same module name is already loaded in memory, the system uses the loaded DLL, so if another plugin depends on a different version of one of your dependencies, there’ll be a conflict and one of the plugins is likely to fail.

I was wanting to statically load these dlls - as I suspected the reason for FL studio failing to load the plugin was a dependency issue, related to the DLLs. However, for some reason, JUCE doesn’t statically link to my dependencies. I tried to add OPTION(BUILD_SHARED_LIBS "Build shared libraries" OFF) which didn’t help

That’s not up to JUCE. The dependencies themselves must be built as static libraries, rather than as dlls. The CMake build scripts for the dependencies probably have ways of requesting static libraries rather than dynamic libraries, but you’ll need to read the library documentation (or the scripts themselves) to find out the correct procedure for each library. The static versions may also have different target names to the static libraries, so you may need to pass different arguments to target_link_libraries.