Hi,
We’re an audio plugin company and we are testing LimeLM for use in our newest product.
We got the standalone (.app) version working perfectly right away, but we have troubles with the plug-in versions (VST3, AudioUnit).
The plugin builds fine, but when we try to open it, the host programs don’t recognize it as such and don’t even load it (They either fail the plugin validation step or just don't load without any error message from the Host Program).
It fails all the same even if we don’t actually use LimeLM, just including the library seems to mess with the host's recognition of the plugin format.
We’re testing it on macOS (non-M1, 2 different machines), following the ‘Using TurboActivate with C, C++, & ObjC’ tutorial, as well as the ‘… on macOS’ section.
Any ideas what could we be doing wrong?
For plugins, things get tricking when linking to other dynamic librarys (dylib) from within a dylib. The search paths in particular get tricky.
For apps, you control this “library search path” using rpath. For “plugins” you're really at the mercy of the loading application.
So, I'd start by compiling with the static version of TurboActivate, get that working, then once you have a clearer idea of where the search paths are for the loading app, switch back to using the dynamic version of TurboActivate.
Thanks for the reply, we actually managed to find the solution.
Like you said, it was caused by linking to the dynamic library, particularly by the use of “@executable_path”.
It turns out that for plugins, “@executable_path” points to the Host’s binary instead of the plugin’s.
To point to the plugin’s binary, we needed to use “@loader_path” instead.
So, using “@executable_path” for Standalone version and “@loader_path” for the Plugins, everything now works.
