JUCE is busted in Xcode 11.4

I know this issue has been well covered but in case anyone is having trouble trying to get it work. I recently was running an earlier JUCE version with Xcode 11.4. It worked fine until yesterday, when for some reason opening a loose .cpp file prompted the “Xcode needs to download and install tools to open this” dialogue. I did so. Later, I started getting the “Point is ambiguous” issue.

After reading this thread, I downgraded to Xcode 11.3 in the hopes it would fix this issue. The issue persisted. Remembering that the issue began after downloading those tools, I went into the Xcode package contents and deleted the “tools” folder after confirming that it contained new content that had been downloaded right before the issue began. This is probably not a great solution my project now compiles.

I suspect I could run 11.4 again without issue, but I’m going to stick with 11.3 for now.

On Catalina 10.15.4.

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

Carbon-Finder-error

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…)

1 Like

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.

1 Like

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. :frowning: 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)

1 Like

Thank you! :smile: 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! :heart: 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 :smiley:

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.