Thanks for the reply. I’m not using cmake, but I can discern the steps from the code you shared.
I might not have been clear in my previous post, but I’ve essentially done the steps you’ve outlined manually:
- copying the dylib into the VST3 bundle in a Frameworks directory
- using
installl_name_toolto change the relative path to the @loader_path path within the bundle on the VST3 binary in the MacOS directory - verifying the library path change using
otool -Landotool -Lon the VST3 binary
However, if I attempt to load the VST3 into a DAW/host after those steps, I observe the following:
- The host will crash when attempting to load the VST3 (from say a demo project that has one instance of the VST3 in it)
- When launching the host via Xcode debugger attached session, projects with the VST3 saved in them will load ok via the @loader_path change. Why would they crash in a non-debugger-attached process, vs. a debugger-attached-process - that seems weird to me, and I can verify it is loading from the bundle when debugging.
- After the changes of moving it to the VST3 bundle as you’ve outlined, the VST3 will no longer scan in hosts (debugger-attached, or not - it basically crashes on scan, something relating to the rpath change apparently).
On top of that, is still doesn’t show up in Ableton, so I gain nothing from leaving it as-is and placing it in /usr/local/lib, and it actually stops working in all hosts.
I’m definitely new to hacking dynamic library paths, and I feel like I must be missing something. Would there be a difference to performing those two steps you’ve outlined in a post build step vs. doing it manually after the VST3 is built as I have done? Because if not, that cmake function would actually make my situation worse, as outlined by the result of applying the steps manually.
It also still leaves me completely unsure what Ableton might be doing differently when loading dynamic libraries that would cause the @rpath/libphonon.dylib + /usr/local/lib location to work in everything except Ableton.