Oddly, if I open a terminal and execute the command manually, it goes fine (the script prints the command before it executes it, so it’s is conveniently available).
What gives ?
I’m actually seeing the same thing on Windows (intermittently).
The other relevant bit of information is that this only happens on one of my plugins (the one that links to some dylibs). Not sure how thats relevant, but I suspect it is since that’s the only difference.
I plan to change this to a warning rather than an error but essentially the VST3 helper has likely failed to load the plugin and therefore generate the manifest. If there are dynamic libs have those libs been signed and copied to the correct location by this point? if not and the plugin tries to load them I imagine that would cause an issue.
For now you may have to edit the Xcode Run Script Phase “Update Manifest” to skip this step (or just remove the step entirely). It’s only a temporary fix but once you’ve done that you can see if your plugin loads from another DAW in order to debug it.
That seems right. In my case the libraries are in the /usr/local/lib directory (which is also set as the @rpath) and they have been signed appropriately.
This is an intermittent issue too … clearly you are right that it’s just having trouble loading the plugin. Could it be a timeout or something like that? If the libraries don’t load quickly enough?
I’m not aware of any specific timeouts we’ve added explicitly. When during the build are the libraries copied to /usr/local/lib? or are they just installed well before building? Maybe you could try debugging the VST3 helper target to see if you can reproduce the issue with a debugger attached?
They are in there well before the build starts, assuming the VST3 rpath has been set, it should definitely find them without issue.
Can’t really debug the vst3_helper unfortunately because this only happens in release mode, debug builds are fine.
I guess I could try adding the dylibs to the bundle (“xcode custom copy directories”, or whatever that option is), maybe that would work differently.
I’ll also mention again, that it does work sometimes (maybe 10% of the time).
The libraries in question, by the way, are AI things (torch / onnx) which are rather large and link to a number of other dylibs and all the rest … so, maybe understandably an edge case to some degree. I would prefer to link them statically, but so far thats been problematic.
Is your release built with an Aggregate target in Xcode?
We experienced intermittent problems with that, because by default Xcode parallelizes the build of all the targets that belong to the Aggregate target.
What was happening in our case was that some of the files that were expected to be there in the post-build phase of one of the targets, were being messed with by the post-build phase of another target that was being built in parallel with that.
The solution in our case was to mark the targets to NOT be built in parallel by the Aggregate target, it is done in the scheme editor.
