JUCE is busted in Xcode 11.4

Ironically, I had just decided to do this exact thing as the only possible workaround when this notification came through. This will definitely work; I can just tell by looking at it. Solid. Thanks!

At this juncture, I’m just thankful that Jules isn’t Scottish. Who the hell knows what “Colour” would have ended up as then? Back to our regularly scheduled program of replacing hundreds of ScopedPointers and Drawable calls.

It has nothing to do with accents! :slightly_smiling_face:

My point being that if he was Scottish, he’d be aggressive-aggressive about using rando nonsense words, rather than passive-aggressive.

So Scottish people are aggressive and ‘rando’ is a real word? Interesting.

1 Like

To save world peace it seems we need to switch to emoji programming:

3 Likes

My wife is Scottish, no comment. :slight_smile:

Somehow reading your link @richie, I cam across this hidden gem;

.frame {
  background-image: url("/queen.png") !important;
}

.hello {
	content: "subjects";
	color: gray;
}
2 Likes

I’m trying to investigate this and I can’t reproduce this issue. Are you using the JUCE built-in VST3 SDK? If not, which commit of the VST3 SDK are you using?

I’ve tried a bunch of different VST3 SDK versions with the current JUCE develop branch, and I’m unable to reproduce any ‘missing definition’ errors.

I have a feeling all 3 of us are using the non-JUCE-built-in version of the SDK to maintain VST2.4 support (correct me if I’m wrong, but the built-in version can’t actually provide VST2.4 support right?)

Is there still an active repo with the last version of the SDK which had 2.4 support somewhere? I’ve not kept track of which commit I am using, but since the SDK source remains unaltered, I’d be happy to try with a later version if one is actually still available.

That’s correct, you must supply your own copy of the VST2 SDK in order to build VST2 plugins. However, I don’t understand why this would affect VST3 builds. It’s possible to use the external VST2 SDK for VST2 plugins while also using the built-in VST3 SDK for VST3 plugins. Would you be able to check whether your build succeeds when using the built-in VST3 SDK?

Perhaps the VST2.4 compatibility mode is enabled? This gives VST3 builds a dependency on 2.4 SDK.

That’s true, but that mode will still work with the built-in VST3 SDK, or a completely separate one. To test, I just built the DSPModulePluginDemo VST3, using a custom VST3 SDK and a custom VST2 SDK, with JUCE_VST3_CAN_REPLACE_VST2=1 defined, under Xcode 11.4.1. I still couldn’t reproduce any build issues.

1 Like

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.