I woke up this morning and found that Apple threw me a shotgun wedding with Xcode 15. Now I seem to have a problem when trying to build VST/AU (standalone works fine). There seems to be a circular reference issue between shared_code and binary data. Before I start dumping endless logs here, has anyone else had this issue recently?
4 Likes
Ok so looks like something funky is going on with VST3 Manifest Helper:
note: Building targets in dependency order
note: Target dependency graph (3 targets)
Target 'Owl Control - VST3' in project 'Owl Control'
âžś Explicit dependency on target 'Owl Control - Shared Code' in project 'Owl Control'
âžś Explicit dependency on target 'Owl Control - VST3 Manifest Helper' in project 'Owl Control'
Target 'Owl Control - VST3 Manifest Helper' in project 'Owl Control' (no dependencies)
Target 'Owl Control - Shared Code' in project 'Owl Control' (no dependencies)
I see that there are some recent posts about similar issues but I should mention that this is a simple project without external dependancies or pre/post build scripts. It just started after upgrading Xcode15, I am using Juce 7.0.7 (project generated with Projucer).
A couple of fixes for this were added after the 7.0.7 master release. If you haven’t already, please try updating to the develop branch and check whether the problem persists.
2 Likes
Yes! Develop branch to the rescue. OK back to work.
I have found another building failure issue of this due to the default value of “Installation Build Products Location” for both the VST target and the AU target.
By removing the customized value of this property, this issue disappears:
I have tried to use the developer branch (move all the files and folders in the folder Juce-develop into my main JUCE folder) however the issue persists, is this not the correct way to move to the develop branch?
No; you also need to rebuild the Projucer from the develop branch, then resave your project using the Projucer you just built.
Ahh i see, thanks. I opened up the Projucer.xcodeproj and built, the error seems to have gone away but is now replaced with a different one. Xcode says it can’t call “mkdir /Builds/MacOSX/build/Debug/plugin.vst3”. So something to do with permissions? I’m unsure what process would be calling this so I wouldn’t know how to configure these permissions properly.
I get this error too. After deleting the build folder once it seems to go away.
Same problem with my machine, XCode 15, AU build fails due to circular references.
JUCE 7.0.7
I think I remember getting something similar that cleaning or deleting the build folder fixed
Has there been a proper solution found for this? I’ve updated to the developer branch, tried deleting the build folder, resaving my project and a bunch of other stuff about 3 times. Is downgrading a good solution for the time being?
Did you also rebuild the Projucer, and resave your project with that copy of the Projucer?
I can’t rebuild ProJucer. I’m getting a Codesign error, specifically:
CodeSign /Users/cr/Documents/GitHub/JUCE/extras/Projucer/Builds/MacOSX/build/Debug/Projucer.app (in target 'Projucer - App' from project 'Projucer')
cd /Users/cr/Documents/GitHub/JUCE/extras/Projucer/Builds/MacOSX
Signing Identity: "-"
/usr/bin/codesign --force --sign - --entitlements /Users/cr/Library/Developer/Xcode/DerivedData/Projucer-gstqwqgxsrfahvgsfgjepepnrbjk/Build/Intermediates.noindex/Projucer.build/Debug/Projucer\ -\ App.build/Projucer.app.xcent --timestamp\=none --generate-entitlement-der /Users/cr/Documents/GitHub/JUCE/extras/Projucer/Builds/MacOSX/build/Debug/Projucer.app
/Users/cr/Documents/GitHub/JUCE/extras/Projucer/Builds/MacOSX/build/Debug/Projucer.app: resource fork, Finder information, or similar detritus not allowed
Command CodeSign failed with a nonzero exit code
Settings:
Any thoughts?
I just built on a (new, fresh) Sonoma machine, and there are none of the issues above. Everything works swimmingly. So I guess I’ll blow out the Github folder on the old machine or some other such nonsense.
I love Apple.
And the plot thickens. I was able to build the dev branch Projucer on the fresh machine and move it to the upgrade machine (where the problems I’m experiencing above are) and PJ a fresh build folder for one of our plugs. The standalone builds fine, but the VST3 throws this:
/Users/cr/Documents/GitHub/Axon-3/Builds/MacOSX/build/Debug/Axon 3.vst3: code object is not signed at all
In architecture: arm64
/Users/cr/Documents/GitHub/Axon-3/Builds/MacOSX/build/Debug/Axon 3.vst3: resource fork, Finder information, or similar detritus not allowed
Command PhaseScriptExecution failed with a nonzero exit code
And again, this is on the upgraded machine, which is my main build machine. The new machine builds fine. I think I’m going to have to assume that the converting of the ~/Documents folder (where my Git repo lives) to the “iCloud” version, and then back, has irrevocably fucked my build workflow, and I’m going to need to blow out the folder and rebuild it elsewhere.
I say all this as a warning to you before updating to Sonoma: I’m not 100% certain that iClouding the Documents folder is the default now, but I’ve had that off since they had that feature, and it was on after I upgraded and my docs folder was “in the cloud.” Your mileage may vary.
1 Like
Sorry but I seem to miss a key point here: what stops you from just nuking the JUCE folder on your dev machine and re-build it from scratch? Why do you need to build it on a new machine and move it to your dev machine? (I am referring to the folder that gets moved to JUCE_old once you upgrade juce version)
I’m experiencing the exact same issue, I don’t have another Mac to test this on, but after disabling cloud syncing, moving everything to a local drive, opening XCode and cleaning the build folder I still get the error.
Edit: Am i missing steps, or is this just an Apple broke XCode again type scenario? If so I’m a bit screwed since I can’t even downgrade to XCode 14 on Sonoma.
Nothing stops me from doing that. Which is why I did it multiple times. This is, as it happens, not my first rodeo.