# VST3 not loading on other Mac **URL:** \ **Category:** Audio Plugins\ **Created:** [November 11, 2020, 12:47am UTC](https://forum.juce.com/t/vst3-not-loading-on-other-mac/42677 "2020-11-11T00:47:35Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![tmtakashi](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/tmtakashi/32/9493_2.png) [@tmtakashi](https://forum.juce.com/u/tmtakashi)\ **Post date:** [November 11, 2020, 12:47am UTC](https://forum.juce.com/t/vst3-not-loading-on-other-mac/42677/1 "2020-11-11T00:47:35Z")
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? ---
**Author:** ![reuk](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/reuk/32/21494_2.png) [@reuk](https://forum.juce.com/u/reuk)\ **Post date:** [November 11, 2020, 10:20am UTC](https://forum.juce.com/t/vst3-not-loading-on-other-mac/42677/2 "2020-11-11T10:20:39Z")
Are both macs running the same version of macOS? Perhaps the deployment target is higher than the OS version of your other mac. ---
**Author:** ![tmtakashi](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/tmtakashi/32/9493_2.png) [@tmtakashi](https://forum.juce.com/u/tmtakashi)\ **Post date:** [November 11, 2020, 1:58pm UTC](https://forum.juce.com/t/vst3-not-loading-on-other-mac/42677/3 "2020-11-11T13:58:39Z")
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? ---
**Author:** ![reuk](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/reuk/32/21494_2.png) [@reuk](https://forum.juce.com/u/reuk)\ **Post date:** [November 11, 2020, 2:17pm UTC](https://forum.juce.com/t/vst3-not-loading-on-other-mac/42677/4 "2020-11-11T14:17:33Z")
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. ---
**Author:** ![tmtakashi](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/tmtakashi/32/9493_2.png) [@tmtakashi](https://forum.juce.com/u/tmtakashi)\ **Post date:** [November 12, 2020, 7:12am UTC](https://forum.juce.com/t/vst3-not-loading-on-other-mac/42677/5 "2020-11-12T07:12:16Z")
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? ---
**Author:** ![reuk](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/reuk/32/21494_2.png) [@reuk](https://forum.juce.com/u/reuk)\ **Post date:** [November 12, 2020, 10:29am UTC](https://forum.juce.com/t/vst3-not-loading-on-other-mac/42677/6 "2020-11-12T10:29:49Z")
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. ---
**Author:** ![tmtakashi](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/tmtakashi/32/9493_2.png) [@tmtakashi](https://forum.juce.com/u/tmtakashi)\ **Post date:** [November 13, 2020, 2:54am UTC](https://forum.juce.com/t/vst3-not-loading-on-other-mac/42677/7 "2020-11-13T02:54:07Z")
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? ---
**Author:** ![PluginPenguin](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/pluginpenguin/32/10203_2.png) [@PluginPenguin](https://forum.juce.com/u/PluginPenguin)\ **Post date:** [November 13, 2020, 9:40am UTC](https://forum.juce.com/t/vst3-not-loading-on-other-mac/42677/8 "2020-11-13T09:40:27Z")
> [@tmtakashi](#): > > 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 😉 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.