Version 4.2, Cant compile on OSX


#1

Hi
Since updating to 4.2, my app won’t compile on OSX, I have made no changes to the plugin hosting code but get some errors that looks like AU-related stuff.
The app compiled fine prior to the Juce update. Last merge I had before jumping to 4.2f was 13. March - 438dbb7
I now get following errors:

/JUCE_lib/modules/juce_audio_processors/format_types/juce_AudioUnitPluginFormat.mm:310:51: Use of undeclared identifier ‘kAudioComponentFlag_IsV3AudioUnit’

/JUCE_lib/modules/juce_audio_processors/format_types/juce_AudioUnitPluginFormat.mm:1564:57: Use of undeclared identifier ‘kAudioUnitProperty_RequestViewController’

/JUCE_lib/modules/juce_audio_processors/format_types/juce_AudioUnitPluginFormat.mm:1567:64: Use of undeclared identifier ‘kAudioUnitProperty_RequestViewController’

/JUCE_lib/modules/juce_audio_processors/format_types/juce_AudioUnitPluginFormat.mm:1576:66: Use of undeclared identifier ‘kAudioUnitProperty_RequestViewController’

/JUCE_lib/modules/juce_audio_processors/format_types/juce_AudioUnitPluginFormat.mm:1924:56: Use of undeclared identifier ‘kAudioComponentFlag_IsV3AudioUnit’

/JUCE_lib/modules/juce_audio_processors/format_types/juce_AudioUnitPluginFormat.mm:1934:53: Use of undeclared identifier ‘kAudioComponentInstantiation_LoadOutOfProcess’

/JUCE_lib/modules/juce_audio_processors/format_types/juce_AudioUnitPluginFormat.mm:1956:57: Use of undeclared identifier ‘kAudioComponentFlag_IsV3AudioUnit’

/JUCE_lib/modules/juce_audio_processors/format_types/juce_AudioUnitPluginFormat.mm:1986:51: Use of undeclared identifier ‘kAudioComponentFlag_IsV3AudioUnit’

Regards
Nikolai


Update from 4.1 to 4.2 to lastest tip Fail to compile
#2

Narrowed it down to the 4.2 commit, updating osx, xcode and all the other apple stuff and see it helps


#3

Perhaps you’re building with an old OSX SDK?


#4

After some coffee, Yes, probably. updating everything now. Let’s see how this goes.


#5

I have the same problem, and I’m certain I DO have a very old SDK. The rationale a few years back was to maintain some sort of backwards compatibility and I’m scared updating either or both Xcode and the SDK. We make a VST/AU/AAX/Standalone which in turn has a built in VST & AU host. Perhaps some of our compatibility problems is due to the age of our tools… but I’m concerned creating new problems with new tools.

What is the furthest we’d be backwards compatible if we updated to the latest Xcode & SDK today?


#6

With JUCE 4.2, as long as you don’t use C++11, you should be good all the way back to OS X 10.6, for this you have to set the “Deployment Target” setting accordingly (notice that this is not the SDK setting which can be the newest).

With C++11, you should be good back to OS X 10.7 if you remember to change the compiler settings to -std=c++11 and -stdlib=libc++ manually.

Please note that we are seriously considering breaking support for OS X 10.6 later this year and going C++11. This would be announced well in advance though.


#7

Alright! Because I use OSX SDK 10.7 with deployment target 10.6. Thusly, upgrading to the latest SDK I could still use 10.6 as a deployment target?

I don’t think I am so concerned about 10.6. We even specify 10.7 as a technical requirement.
Thanks.


#8

Just to confirm what everybody has figured out, yes it has to do with SDK version.
I’m to a bit confused about the relationship of SDK version VS deployment target.
Do I understand it correct that I can set deployment target to 10.8, use the latest SDK and everything is good on 10.11?


#9

My understanding is that the deployment target is just a flag in the binary to help OSX determine if the program can be executed or not. It is the programmers responsibility to make sure he or she do not use API’s not available in the deployment version.


#10

No, it’s not that simple. Xcode does some pretty clever stuff to make sure you don’t call anything that isn’t available on the lowest version that you’re targeting.


#11

So I would know at compile time the binary would never execute? That is really good. I always thought it would be a nasty surprise… like people calling in to technical support after 2 weeks.


#12

Is the deployment target really enough? I’m asking because someone told me a while ago that the only way to really make sure you are fully backward compatible is to use the the SD for the oldest os version that you want to support. I would be really relieved if the deployment target is enough.

http://stackoverflow.com/questions/15091105/confusion-of-how-to-make-osx-app-backward-compatible-how-to-test-them


#13

Only Apple could give you a definitive answer, but I think most people use the deployment target.


#14

The deployment target is enough so that the app will launch.

However if you linked to an SDK that is newer than the deployment target, it’s your responsibility to not call any SDK functions that are newer and don’t exist yet on that older deployment target OS X version. The compiler won’t catch that due to what Apple calls “weak linking”. If your app calls an SDK method that’s not there on the OS you are running, it will crash at runtime. It’s your responsibility to make sure that won’t happen.

fwiw, afaik JUCE itself does not call such methods that would cause your app to crash on 10.6.


#15

Is there still support for 10.6 or did you already break it? I had some issues compiling the code for 10.6 also without c++ 11.


#16

afaik, It should still work on 10.6 as long as you use C++98 and libstdc++. It will not be supported anymore in the future, though.
Why do you need to support 10.6, and exactly what issues are you experiencing?


New Introjucer command-line option: --fix-broken-include-paths
#17

It works perfectly fine on 10.6 also with C++11 and even when using C++14. You just have to use the libstdc++ lib (some features of JUCE aren’t available with that configuration, JUCE_COMPILER_SUPPORTS_LAMBDAS isn’t set and so one cannot use JUCE’s AudioProcessorValueTreeState).

Plenty of folks are still using 10.6.8 (You can search gearslutz for anecdotal evidence). Some have a system that works for them and just they don’t want to break it, and some use software or hardware devices that are not supported on newer OSs. Not everyone are technophiles like us who want to use the shiniest new system…


#18

Thanks for that gearslutz link! Very insightful.

If that’s the reason folks are still on 10.6, then they can also stay on older versions of their music software that still supports it, right? I don’t think this means that the newest JUCE would have to keep supporting 10.6 forever.

What do you guys think?


#19

I believe the only reason some users are staying on 10.6 is because they have illegal software/plug-ins which won’t work if they update.

Rail


#20

There are plenty of legitimate reasons.

For example: Some people are using old Mac Pros with expensive PCI cards that they invested in that just wouldn’t work on newer macs (which don’t support old PCI), or other hardware that doesn’t have updated drivers, such as TC PowerCore or Digidesign/Avid stuff. Some of the stuff is discontinued so they just can’t buy the new version. They want to keep using the same effects and instruments that they like and their old sessions are saved with.