The juce_vst3_helper has to run the plugin at build-time in order to generate the moduleinfo.json that gets included in the plugin bundle. If the juce_vst3_helper can’t load the plugin, then this step will fail. You can search the forum to find some methods for temporarily disabling the manifest generation step if necessary, but I’d recommend including the moduleinfo.json if possible.
That’s correct, yes. It may be able to support this workflow by building a universal binary, generating the manifest, and then postprocessing the universal binary to remove the Intel portion of the binary using lipo -thin.
I had another library dependency with seperate libraries for intel and silicon which made me decide to build JUCE the same way, but I’ll just change my approach and use lipo to make the library a universal one as well, and build JUCE universal. Thanks for the reply.
I’m having the same problem in the other direction. Building on Silicon but targeting for Intel. I’ve been doing this successfully for awhile using Juce 7.0.8. Now I’m setting up a new build machine, and downloaded Juce 8.0.1. Same .projucer and source files on both machines, and it’s failing under 8.0.1. Both machines are Silicon Sonoma 14.6.
Is this a Juce 8.x artifact? I don’t have an Intel build machine anymore. I suppose I could try the universal binary hack, or just capture the files on the “good” build machine and copy them manually. Or go back to 7.x and call it a day. But I’m curious about why this is happening.
Do you have Rosetta 2 on the Arm mac? You’ll need that installed in order to run Intel-only binaries. If you don’t want to install Rosetta 2, then building a universal binary might be a good alternative.