Oh damn not sure why “EXPANDED_CODE_SIGN_IDENTITY_NAME” would be unbound. Does it work from the Xcode GUI?
Hmm I wonder if CODE_SIGNING_ALLOWED=NO means Xcode doesn’t expand those variables 
Yep, it works from the Xcode GUI
OK I can reproduce the issue, if you want a temporary fix dropping the CODE_SIGNING_ALLOWED=NO would prevent this specific error if that’s something you can do? if you haven’t set any other code signing arguments then it should only perform an ad-hoc code-sign using the “-” identity.
@dev1am I have a fix working its way through CI now 
2 Likes
@dev1am a fix is now on develop, let me know how you get on
Now it works, thank you! 
1 Like
I’ve just updated from JUCE 7.0.7 and Xcode 14 to JUCE 7.0.12 and Xcode 15.1, and a change made in one of the new JUCE versions has broken my plugin installer script / workflow. It is related to the change in the process of copying the plugin binaries from the build directory to the plugins directories, which has been discussed above.
The issue is that I’m using the DEPLOYMENT_POSTPROCESSING=YES custom Xcode flag (set in the projucer project) to strip the binaries of symbols, however it appears that this stripping process is happening after the binaries are being copied as the build directory binaries are stripped but the plugin directory binaries are not. This is an issue as my installer scripts use the plugin directory binaries.
It may be acceptable for me to just change the installer script to use the build directory if that’s the only option (and I’m aware it’s the recommended option), but it would be less disruptive if the plugin directory binaries are stripped as well. Are there any solutions to this?
I’ll take a look. However, if Xcode is applying this post processing stage after the post build script runs then on our end we could try to duplicate this process manually in the copy step. Unfortunately this is riddled with issues that we’ll likely prefer avoid. We did this for signing but really we had to as signing is a requirement for debugging Apple Silicon builds.
On your end a quick fix may be to do the copy of the plugin yourself after the Xcode build is finished and only rely on the plugin copy step for debugging?
Thanks - though completely understandable if it’s a pain to change.
Hello all,
What exactly solution for cmake ?
I upgraded to xcode 15.4 then vst3 build failure.
I am using juce version: 7.0.12
AU/Standalone build OK
VST3: build error
/NDIReceiver_artefacts/Release/VST3/NDIReceiver.vst3: code has no resources but signature indicates they must be present
-- Replacing invalid signature with ad-hoc signature
/NDIReceiver_artefacts/Release/VST3/NDIReceiver.vst3: replacing existing signature
removing moduleinfo.json
The bundle “NDIReceiver” couldn’t be loaded.Command PhaseScriptExecution failed with a nonzero exit code
Check your release folder.
Does the .vst3 exist?
From the output, it looks like something is going wrong when the VST3 manifest helper is attempting to load the plugin. I’m not sure how an Xcode upgrade could cause this. Did things definitely work with an older version of Xcode? Did you change anything else at the same time as upgrading Xcode?
Yes, It does exist
Thank you for your reply @reuk ,
Did things definitely work with an older version of Xcode?
=> Yes, Everything build OK on xcode version 13.4.1
Did you change anything else at the same time as upgrading Xcode?
=> No, I didn’t change anything. BTW, I tested on another Mac with version xcode 15.1, and also build error.
It sounds like the .vst3 is being built successfully, it’s just the manifest generation that is failing.
If you take the built .vst3 file and manually copy it to ~/Library/Audio/Plug-Ins/VST3, are you then able to load it successfully in a VST3 host?
I’ve had the same issue in the past occasionally, and it was solved in the past by regenerating the XCode project, and / or cleaning the solution.
What exactly does the manifest generator do?
No, the host can’t load (tested with ableton live, AudioPluginHost).
OK, I can think of a few possibilities. In order of probability:
- If the host is crashing/erroring when attempting to load the plugin, then there could be a bug in the plugin itself. You can debug as normal (attach a debugger to the AudioPluginHost before loading the plugin) to diagnose and fix the problem.
- If the plugin is linked to other shared libraries, then perhaps one or more of these libraries cannot be found when the plugin is loaded. Consider linking statically instead, unless you have a very good reason not to. You can find library dependencies by running
otool -L /path/to/plugin.vst3/Contents/MacOS/plugin. Dependencies in/System/Library/Frameworksand/usr/libare probably fine, but others may cause problems. - If the host is refusing to load the plugin at all, then perhaps the plugin bundle is not signed correctly, or the plugin is built for a different architecture than the host.
- You can check the plugin’s signature by running
codesign -dv /path/to/plugin.vst3. The plugin must have a signature of some kind. I’d be surprised if a broken signature was the cause of the problem, as it looks like the plugin is being signed successfully based on the original output you shared. - You can check the target architecture of the juce_vst3_helper and your plugin by running
file /path/to/juce_vst3_helperandfile /path/to/plugin.vst3/Contents/MacOS/pluginrespectively, adjusting the paths as appropriate. The plugin architecture must match at least one of the juce_vst3_host’s architectures. I’d also be surprised if this was the cause of the problem, because CMake should build everything for the same target architecture unless you’ve explicitly told it not to.
- You can check the plugin’s signature by running
The manifest generator loads the plugin and generates a file named moduleinfo.json that lives inside the VST3 bundle. This file can be scanned quickly by hosts to determine a plugin’s capabilities without needing to load the plugin itself, which can improve load times. More info here.
2 Likes
Thank you very much, reuk,
After double check, I found out that it was wrong to link dependencies (curl lib).
Sorry for asking … is this still the accepted and recommended way to go? We are now on 15.4 and with the new MacOS version on the horizon, I wonder if there are further changes on Apples side?