Hello, I just installed JUCE 7.0.6. I did not have the problem below with 7.0.5.
On MacOS, there is a new build phase, I think only for VST3 builds, named Update manifest, that was not there before, and it is in this new phase that my build is failing. The Xcode build window includes the lines below.
Run custom shell script 'Update manifest'
/Users/david/emvoice/dev/working/VOICE/sohoplugin/Builds/MacOSX/build/Debug/emvoiceone.vst3: code object is not signed at all
In architecture: arm64
The bundle “emvoiceone” couldn’t be loaded.
Command PhaseScriptExecution failed with a nonzero exit code
I don’t quite understand why the plugin should be loaded and executed at this point in the build. I think that the failure to load the VST3 plugin is what leads to the PhaseScriptExecution failure, but really I am not certain about this.
The failure occurs before the post build script runs.
It took me a couple of days to understand this issue.
We link our plugin with multiple external libraries. On MacOS this means that our plugin links with multiple *.dylib libraries. Our plugin can not run unless all of these dylib files are available.
In our case, whether for the AU build, the (legacy) VST2 build, the AAX build or the VST3 build, the dylib files are copied into the plugin bundle, always into the folder Contents/Frameworks, and the plugin ships with these dylibs. Otherwise, we can not be certain that these dylibs will be on the user’s machine. So for example, our post-build script has the following lines (surrounded by, of course, a lot of other logic)
As far as I know, it is pretty standard stuff on MacOS to copy the dylib files into the bundle. We have made this work for about 5 years since JUCE 4.
So the problem we are having is that this copying happens during the post-build script (It can not be done during the pre-build script, since the bundle might not exist at that time.). But in JUCE 7.0.6, there is a new phase Update manifest that runs a script before the post-build script, and this Update manifest script attempts to run the VST3 build of our plugin before the dylibs are copied into position. So of course the VST3 plugin fails to load.
It seems to us that loading and running a plugin before the post-build script completes is a flaw in the JUCE 7.0.6 plugin build process.
Is there a work around for this? We don’t need the VST3 to be loaded during the build and before the post-build script runs. We really want to be able to use the latest version of JUCE, but can not now because of this problem.
The loading is required for a somewhat new VST3 feature, the manifest, that contains all the information that a DAW would want to find out when scanning a plugin first. This way, instead of scanning the plugin, it can just read a .json file, which is many times faster. In order to generate this .json file, we are scanning the plugin right after building it to populate the contents of the manifest.
I can see how this is causing a problem for you, and we should find a way to accomodate your build process.
I considered the options here and I have a suggestion that may work for you.
First of all I think the manifest generation is a very useful feature, that you may want to support if it only requires a one-time build modification. If all plugins supported it (and the idea is that eventually they all will), on a system with lots of plugins it can mean the difference between a DAW startup time of one minute vs. a couple of seconds.
Can you see please, if you could move the .dylib copy step into the Pre-Build script after all? There’s a good chance you could make something like the following work.
Thank you very much. I moved the dylib copy step from the beginning of the post-build script to the end of the pre-build script. It works perfectly. Very good idea.
And thanks for the explanation of why JUCE added the update manifest step in the first place. It makes sense to have this info calculated once and saved in a JSON object that goes as part of the VST3 bundle instead of the DAW calculating it each time the VST3 is loaded.
Now I understand why in Windows builds of the VST3 in JUCE 7.0.6, a bundle is created (instead of just a single DLL): so that there is a place for the manifest.
One question: do you have any sense of if or when (in Windows) VST3s in the form of a single DLL will be forbidden, and the full bundle containing the DLL and the manifest will be required? Is this going to happen?
I’m able to compile locally, directly from Xcode and VisualStudio. I’ll have to configure the same setup of pipelines locally in order to find the problem
This whole moduleinfo.json feature seems too fragile at the moment to be imposed to everyone that switches to 7.0.6.
In my opinion it would be better to call it experimental, and to give developers a way to opt-out if it’s not working for them at present time.
Hope the JUCE developers did research to know how commonly the bundle version is supported. I really have no idea myself so just waiting to see if complaints start to roll in.
So I am also facing the same error message (“DecentSampler.vst3: code object is not signed at all”), also in the Update Manifest step, but I don’t do any .dylib copying in a post-build step. In fact, I think I have a pretty vanilla build.
It sounds like the failure is probably happening when running the manifest-generator tool, but if the above commands complete successfully then we’ll know for sure.
Some other details that would be useful to know:
Do you have any non-default options set in the Projucer, e.g. hardened runtime, app sandbox, legacy build system
Does the path to the build directory contain any non-ascii characters such as diacritics?
Light at the end of the tunnel! I have a bunch of Custom Xcode flags that I added for a bunch of different reasons, none of which I can remember anymore. I would need to search through the JUCE forums to figure out which thread the various flags were lifted from.
In any case, when I remove all of these flags, Xcode Archives my plugin just fine. I’m now working my way through to try to figure out which of these flags is causing the problem. Here are my Custom Xcode Flags:
My guess is that the problem originates here - I think these flags will apply to all targets (not just the plugin), so the manifest generator will be built with the hardened runtime. This fails because apps using the hardened runtime can’t load adhoc-signed bundles, and the bundle isn’t release-signed until after the manifest is generated.
I recommend instead just setting OTHER_CODE_SIGN_FLAGS=--timestamp, and setting “Use Hardened Runtime” to “Enabled” in the Xcode (macOS) exporter in the Projucer. The Projucer knows that when the option is set here, it should only apply to the final plugin binary, rather than to every target in the project.
