VST3 not loading on other Mac

Hi, I built a plug-in with the JUCE CMake API, and it runs well on my develop machine.
However, when I tried to load the release version of the built VST3 package on REAPER on my other Mac, it doesn’t even recognize the plugin.
I’ve placed the package in the plug-in path, and tried rescanning it.

Does anyone know how to solve this problem?

Are both macs running the same version of macOS? Perhaps the deployment target is higher than the OS version of your other mac.

Actually, I have different versions of macs on my machines.
What is the walk around with this problem?
I’ve looked at the documentation here:


but I’m quite confused because it says

The -DCMAKE_OSX_DEPLOYMENT_TARGET=9.3 option sets the minimum deployment target (it applies to iOS despite the ‘OSX’ in the variable name!).

So what I should I do instead?

Sorry, I can see how that would be confusing. That should read “it also applies to iOS…”. That is, depending on the CMAKE_SYSTEM_NAME, CMAKE_OSX_DEPLOYMENT_TARGET will set the deployment target for the appropriate platform. If you don’t set the CMAKE_SYSTEM_NAME at all, then -DCMAKE_OSX_DEPLOYMENT_TARGET=10.13 will set the macOS deployment target to 10.13.

Thank you for helping me out, but unfortunately it doesn’t seem working.
My development machine is Catalina, and the one that I’m trying to run on is Mojave.
These are the commands I used to build the plugin.

cmake -Bbuild -DCMAKE_OSX_DEPLOYMENT_TARGET=10.13
cmake --build ./build --config Release --target 3DGuitarAmpRenderer_VST3 – -j 10

Is there any other possibility that you can think of?

I just tried building the AudioPluginHost and the DSPModulePluginDemo from the JUCE repo on a mac running the Big Sur beta with the deployment target set using -DCMAKE_OSX_DEPLOYMENT_TARGET=10.13. I was then able to open and use the built products on a different machine running Catalina. I think the issue may be elsewhere.

Does your plugin have any non-JUCE dependencies that aren’t being copied to the other machine? Maybe it’s looking for shared libraries, presets, samples etc. in a particular location that isn’t present on the Mojave machine.

Failing that, you could try running the AudioPluginHost under a debugger on the Mojave machine and then loading your plugin. Hopefully this will let you work out at which point your plugin is failing to load.

Thanks for your time trying it out!
Actually, my plugin depends on FFTW.
This might be a general C++ development question, but is there any way for me to include the FFTW library in the plugin binary so that I don’t have to bother with such dependency issues?

Yes there is, it’s called static linking :wink:

Generally there are two types of libraries, dynamically linked libraries and static linked libraries. Dynamic libraries are not part of your plugin or application binary, so the plugin or application has to find it in a known location at startup. This way you can update the library and the plugin separately and the plugins binary size stays smaller, especially when you ship multiple versions (VST, AU, AAX…) of the plugin, all using the same lib. All system frameworks work this way, this allows e.g. your operating system to use different versions of a library, depending on the hardware you are running on. While you can rely on the system libraries to always be where the plugin expects them (with the Microsoft Visual C++ runtime library being the only exception to that), for dynamic libraries you have to take care of that yourself by making your installer install the library or embedding it in the plugin bundle.

In contrast to that, statically linked libraries are only needed at compile time, as they become a part of the resulting binary during the linkage step. With all the pro arguments for dynamic libraries stated above, static linked libraries are preferred by many developers, as they will just work, you don’t need to put any more effort in making your plugin portable between your build machine and any other computer out there.

Dynamic linked libraries have the file extension .dll on Windows, .dylib on MacOS and .so on Linux. Static linked libraries have the file extension .lib on Windows and .a on MacOS and Linux.

That being said, did you consider just using the built-in FFT functionality of JUCE instead of using FFTW? I know of the great performance of FFTW but for some use cases the performance of the juce::dsp::FFT will be more than enough, especially on Apple, where it uses the Apple Accelerate framework under the hood. In case you are targeting Apple only, you can also directly use the Accelerate FFT and maybe squeeze out some more performance by directly using the split complex data layout that Apple sets as default. These options would both save you from thinking about library linkage.