macOS: juce_vst3_helper: command not found

[phraemer]

With this develop commit from yesterday

Windows WebView2: Fix build on C++17 · juce-framework/JUCE@aceef4f (github.com)

we’re getting the following error when building a vst3 on macOS

./builds/cmake-build-macOS-PLUGINNAME/PLUGINNAME.build/Release/PLUGINNAME_VST3.build/Script-083EAEF2262F3A97376E98B7.sh: line 17: juce_vst3_helper: command not found

Now we jumped from this commit which builds fine so I don’t know at which exact JUCE commit the change occurred:

Widgets: call repaint() in colourChanged() callbacks

Xcode 14.2
cmake version 3.26.4
macOS 12.6.6

[phraemer]

This is the commit which causes the error:

VST3 Client: Enable manifest generation globally · juce-framework/JUCE@c509a18 (github.com)

Don’t know why yet.

[phraemer]

Ok so since we previously were not using VST3_MANIFEST_ENABLED the lines below were not added to each configuration’s section in the generated build script. Now that they are added it fails because juce_vst3_helper is not in the path for whatever reason:

  /usr/local/Cellar/cmake/3.26.4/bin/cmake -E remove -f /Users/builder/build/cmake-build-macOS-PluginName/PluginNameDev_artefacts/Debug/VST3/PluginNameDev.vst3/Contents/moduleinfo.json
  /usr/local/Cellar/cmake/3.26.4/bin/cmake -E make_directory /Users/builder/build/cmake-build-macOS-PluginName/PluginNameDev_artefacts/Debug/VST3/PluginNameDev.vst3/Contents/Resources
  juce_vst3_helper -create -version 2023.5 -path /Users/builder/build/cmake-build-macOS-PluginName/PluginNameDev_artefacts/Debug/VST3/PluginNameDev.vst3 -output /Users/builder/build/cmake-build-macOS-PluginName/PluginNameDev_artefacts/Debug/VST3/PluginNameDev.vst3/Contents/Resources/moduleinfo.json
  cd /Users/builder/build/cmake-build-macOS-PluginName

[reuk]

CMake should automatically insert the correct path to juce_vst3_helper in the post-build script. Have you tried reconfiguring the project from scratch, i.e. generating a whole new build folder, rather than reconfiguring an existing build folder? If so, do you get the same result?

[phraemer]

Yep always rebuilding from scratch.
I made the issue reproducible in this repo:

GitHub - phraemer/juceissues: For exploring and reporting JUCE issues

[alejocazu]

I confirm there’s an issue with juce_vst3_helper - I cannot compile vst3 on a mac (error is thrown) and in PC it “seems” to compile, but when I go and check, the vst3 is a folder (?) and next to the VST3 folder there’s a folder called VST3 Manifest Helper with file juce_vst3_helper.exe in it.

The way I “solved” it was to use the ‘release’ version of procujer.exe placed in the development branch folder, I am not sure if there is any conflict, it seems to work, but I assume this doesn’t cut it.

Additionally, for some reason, a “VST3ManifestHelper” is added in the solution while it didn’t exist on the ‘release’ version of juce

It’s as if the VST3 was split in two

PS: Using Projucer and not CMAKE.

[reuk]

@alejocazu

(error is thrown)

What’s the error, please?

@alejocazu

the vst3 is a folder (?)

This is the expected behaviour. Single-file (non-bundle) VST3 plugins are deprecated since SDK version 3.6.10:

https://steinbergmedia.github.io/vst3_dev_portal/pages/Technical+Documentation/Locations+Format/Plugin+Format.html#for-the-windows-platform

@alejocazu

Additionally, for some reason, a “VST3ManifestHelper” is added in the solution while it didn’t exist on the ‘release’ version of juce

The manifest helper is a recent addition. The manifest helper is a commandline tool that loads the built VST3 and generates a manifest file (moduleinfo.json) that lives inside the plugin bundle. The purpose of this file is to allow hosts to scan plugins without needing to load them, which should speed up plugin scanning for hosts.

[alejocazu]

Understood, thanks for the clarification - so I have to distribute the “vst3” folder, and can I skip the “manifest” one?

So back to the bug though, I again tried to compile a vst3 with the latest dev. branch build, and this is the error I am getting:

I tried deleting derived data, of course cleaning build folder, issue happens compiling both debug or release versions, either arm64 or x86.

I hope this is related to OP’s issue and I am not hijacking the thread :')

[reuk]

@phraemer

I made the issue reproducible in this repo:

I can reproduce the issue in that repo, but the JUCE version there is not the current develop. I think the issue was fixed here:

CMake: Avoid marking juce_VST3ManifestHelper.mm as HEADER_FILE_ONLY

Please try updating to current develop and let me know if the issue persists.

@alejocazu

Understood, thanks for the clarification - so I have to distribute the “vst3” folder, and can I skip the “manifest” one?

You should distribute the directory “yourplugin.vst3”. You should not distribute the manifest helper.

@alejocazu

So back to the bug though, I again tried to compile a vst3 with the latest dev. branch build, and this is the error I am getting:

I’m not able to reproduce this building the AudioPluginDemo VST3 from develop using Xcode 14.3.1 on an M1 machine.

Are you able to build any of the JUCE example VST3s successfully? If so, perhaps the issue is due to something in your particular project.

• Does the project or VST3 name contain any non-ASCII characters?
  • If so, perhaps there’s some part of the build that is is not handling unicode strings correctly.
• Does the VST3 build and load successfully in a host when built using an older version of JUCE?
  • If so, the problem is likely something in JUCE. If not, perhaps there’s a bug in the plugin itself that causes it to crash when it is loaded by the manifest writer tool.

[alejocazu]

Will get back to you reg. all the questions when at the office, but for now I can tell you that:

The plugin is an ‘old’ plugin that compiles perfectly fine with the current release version of juce… if I use the “release” version projucer using the dev. branch files, it compiles fine (although I guess this might bring its own issues? not sure), but if I try to compile with a home-built projucer, it won’t compile.

Also, in Windows, everything works normally.

So yeah, VST3 builds and loads perfectly fine either using the current release version of juce OR the release version of projucer using the dev. branch files.

Also, all characters are ordinary English and numbers, nothing “weird” going on in that regard.

[phraemer]

@reuk

I can reproduce the issue in that repo, but the JUCE version there is not the current develop. I think the issue was fixed here:

Yes it seems to be fixed on the latest commit, thanks!

[reuk]

@alejocazu

if I use the “release” version projucer using the dev. branch files, it compiles fine

Does the resulting plugin load + run correctly in the JUCE AudioPluginHost and/or other hosts?

Have you tried building on other Macs? If so, does it fail in the same way on all machines?

Which version of macOS and Xcode are you using for the build?

[alejocazu]

Ok so I found the issue!

For some reason, I cannot have “Use Hardened Runtime” enabled, if I do, I get the error…

Won’t I need that though for notarizing my plugin?

(XCode 14.2)

[reuk]

Thanks, I think I see the issue. When the hardened runtime is enabled, all targets use the hardened runtime, so the helper tool has strict library validation enabled when it tries to load the plugin, which fails because the plugin isn’t release-signed at that point.

Given that the helper tool should never be distributed to end users, we can disable the hardened runtime just for that target:

Projucer: Disable hardened runtime for LV2 and VST3 helpers

Please try out this change and see if it fixes things for you.

[alejocazu]

Perfection!