the same with me
Iām experiencing this issue again as we ended tracking changes in technical preview branch, and then bumped to official juce6 now that itās out.
Before I look more deeply into this, I am noticing that the new Projucer only provides a VST_SDK-related path for the legacy (2.4) SDK. I assume this is because JUCE6 is now hard-wired for using the internal VST3 SDK for VST3 builds?
If so, would this answer the question of whether the issue persists in this scenario?
(this is on XCode 11.3.1 and 9.4.1)
There havenāt been any new changes related to Xcode compatibility on develop
, and everything from the technical preview should be on develop
now. Additionally, the Xcode versions you mention are from before the 11.4-induced turmoil, so I suspect any issues youāre seeing are something new, unrelated to Xcode version.
Could you supply any more details about the problems youāre seeing? Whatās the exact text of the error messages you see? Which files/lines produce the error? Are you using any non-default module options or preprocessor definitions?
Hi reuk,
This was in reply to see if using the built-in VST3 SDK changed the outcome of having build issues related to the OPās comment (āReference to āPointā is ambiguousā).
SynthDanās fix re-copied below continues to provide a workaround to allow to build, but Iām unsure if this might cause other problems, i.e. causing other issues upon upgrading to XCode 11.4:
Sorry, I havenāt tried that. But I discovered I can get around the issue by putting #include <CoreFoundation/CoreFoundation.h> back in juce_TargetPlatform.h, effectively undoing this change to juce_TargetPlatform.h:
I am seeing this error in the file MacTypes.h for macOS 10.13 SDK, L.542-543:
typedef struct Point Point;
typedef Point * PointPtr;
And no, I donāt believe we are using any non-default module options or preprocessor definitions
When I last investigated this issue, I tried some builds with both the bundled VST3 SDK, and some external ones. I didnāt encounter any issues at that time.
Iāve just tried doing a build of the AudioPluginDemo, using the following setup:
- Newest JUCE
develop
(JUCE 6) - Bundled VST3 SDK
- Xcode 11.3.1
- macOS 10.13 base SDK
- macOS 10.11 deployment target
This build also succeeded without errors.
Are you definitely using a recent JUCE? Have you made other modifications to the library source? The current JUCE develop
should build on all versions of Xcode from 8 (maybe older) without any modifications. Iād recommend checking out the latest version of JUCE and testing it without making any changes to the library source.
As an update, I have resolved my issues while updating my JUCE fork to latest 6.0.1 tip and attempting to use newly recommended best practices, such as setting the DONT_SET_USING_JUCE_NAMESPACE macro and then qualifying all uses of JUCE classes with the juce:: namespace prefix.
What remained were errors that mysteriously only stopped 32-bit builds from succeeding. The way I fixed it was by reversing the order of includes in juce_VST_Wrapper.cpp, namely
#include "../utility/juce_IncludeSystemHeaders.h"
#include "../utility/juce_IncludeModuleHeaders.h"
(by including SystemHeaders before ModuleHeaders rather than after)
This seems to have to do with the #defines in ModuleHeaders:
#define Component juce::Component
#if JUCE_MAC
#define Point juce::Point
void repostCurrentNSEvent();
#endif
Without this change I got errors for 32-bit builds related to Point and Component in Finder.h, all similar to the attached image
Would it be possible to swap the header order in the JUCE tip as well?
Which version of Xcode are you using? I assume this isnāt a problem with Xcode 11.4.
Hi t0m,
Yes at this point my topic has probably diverged from the original thread topic enough to warrant its own thread. However there seems to be a pattern in dealing with XCode update compatibility which seems to somewhat match the original topic.
At this point I believe I have constrained the problem to legacy 32-bit build support, for which XCode 9.4.1 is the very last version where a user can build for 32-bit. The product Iām supporting may have a surprising amount of 32-bit users I canāt drop support for yet. So I think maintaining compatibility specifically with this version of XCode is still worthwhile.
More directed to other devs reading this thread in case they face similar issues:
- my solution to ongoing build support has been similar to REAPER, a legacy set of builds for 32-bit or 64-bit targeting macOS 10.9-10.14 built on XCode 9.4.1, and a 64-bit-only notarized build for 10.15+ using XCode 11.3.1 (no changes seem needed for Big Sur so far, but my one remaining unknown is whether Iāll be able to continue to deploy the Catalina build for Big Sur from XCode 11.3.1, the last to run on Mojave). Iāve not yet had users wanting builds for older OSes than 10.9, but these days more and more users are staying on older versions of macOS somewhere between 10.9-10.14, often due to driver support ending for their sound cards, using an NVidia GPU in their mac pro, etcā¦
Crossing my fingers Iāll be able to continue to build for the complete supported range of macOS versions from a single machine (including Big Surā¦)
Is there a fix for JUCE plugins not being able to debug? I get a rez error for AU and VST3 doesnāt let Ableton open, it says āopening Abletonā then it says āfinished opening Abletonā with no Ableton popping up. I had this problem earlier this year but some how it fixed itself. Iām on JUCE 6 and Xcode 11.3.1.
Are you on Catalina? You can no longer debug processes on macOS that use the hardened runtime unless they have the com.apple.security.cs.debugger
entitlement. You can debug using a host like Waveform or you can try to resign Ableton Live and add the entitlement: Apple Gatekeeper notarised distributables
Iām on Mojave, but might upgrade to Catalina soon. Does Mojave have hardened runtime too? I tried googling if Mojave had hardened runtime couldnāt find an answer. Is there an apple dev resource for this kind of stuff so I donāt run into this kind of thing again in the future? thank in advance.
Yes, hardened runtime was added in Mojave.
Can I use Waveform for debugging and will that solve me issue or will I need com.apple.security.cs.debugger entitlement? Sorry Iām new to programming and Iāve been dealing with this issue for a couple of weeks. thank you in advance
Yes, you can use Waveform without any changes. It will host VST/VST3/AU.
Got wave form to work for debugging but canāt get my AU or VST3 to show up in the plugin folder. Do I need SD NOTARY in order for my plugins to show up after scanning for them? Iāve been googling like a mad man and using trial and error to get my plugin to work, but no luck. Its seems that wave form see vst3 plugins when Iām running in AUv3 for some reason, but AUv3 doesnāt work. AU gives me a rez error. I wish there was a juce article about this stuff. thank for helping g-mon. I appreciate it.
Waveform will host AU, I donāt think itāll host AUv3. You may need to reboot once after creating your AU or try killall -9 AudioComponentRegistrar
Not sure why VST3 wouldnāt show up. Try dragging / dropping the VST3 plugin onto the plugin list to see if itāll scan that way. (Waveform should just pick up new plugins if you have the Enable plugin copy step
enabled in Projucer)
Thank you! I figured it out. I was in root for some reason while in debugging. I got it to work with your help. thank you again. Now I can practice! YESSSS! JUCE Community!
Read to the end, youāll get a laugh.
I came across the dreaded ambiguous Point issue after updating to the latest version of JUCE. I discovered that it was due to
#include āFoundation/NSFileManager.hā
#include āFoundation/NSString.hā
ā¦and the associated code. Temporarily removing that solved the problem.
I heard from Jules that moving system headers before JUCE headers would solve the problem but in doing this (and assuming the above headers count as said system headers) I got errors such as āUnknown type name NSFileManagerā.
So in my absolute desperation after looking for solutions on-line I decided fuck it and renamed all instances of Point in the JUCE repo. The refactor feature in Xcode helped with most of the 185 files. I decided to chose the name āPointeā based on your suggestion
Edit: what am I supposed to do ?!?!?
My solution was to wrap all the stuff I need to include for iOS (and, I guess, AUv3 on macOS if youāre one of those crazy fuckers) in #if JUCE_IOS
Thereās no conflict on the Mac/iOS side of things, so problem solved.