JUCE and macOS 11 / ARM

Was running into this issue myself and this was helpful! After some digging around on the Apple forums I also discovered that library validation is only available for macOS 10.9 and up. I was able to get my AUs to run in ARM mode by including the Runtime Exception you suggested, but changing the OS target to 10.9 or higher also fixed the problem without needing that exception.

Im wondering now why this is only an issue with the ARM builds, if library validation doesn’t work when you target 10.8 why isn’t that an issue for Intel builds? Seems like we might keep discovering some back compatibility quirks with these Universal Binaries for a while.

2 Likes

It’s interesting you find it works with 10.9 and higher as I target 10.11 so by that theory it doesn’t quite match up, there must be something else going on.

1 Like

I’m in the same situation as you have been (plug-in failing when rescanning in Logic because of complaint regarding “arm64e” architecture, and manually launching “auval -comp” says that it couldn’t find the component)

Have you been able to find the problematic settings that cause that?

(might have to spawn a new topic about that shortly if I cannot find a solution soon)

I think removing QTKit framework from Xcode project will do the trick. Don’t forget to clean project before building (for a start, i suggest you to manually delete existing/non-working component file as well).

Thank you, but the fact is that QTKit has never been in the project so that can’t be the cause.

I’m seeing the same problems with a plug-in compiled from a default plug-in project just created with Projucer. Time to create a specific topic on the subject

Done so, the new topic for that specific issue is: Default AU from Projucer fails auval on Apple Silicon Big Sur (DTK) [SOLVED]

I’d be interested if @zabukowski (or whoever is happily validating AUs on their ARM64 macs) could comment there with the version number of auval that they have (and possibly of macOS, I guess that might be a factor too)

EDIT: I’ve solved the issue, visit the linked topic for the detailed description of what the problem was

How are you able to target 10.8? The min Xcode version for ARM is 12 and the lowest possible target sdk appears to be 10.9 or am I missing something?

My mistake, I set the target in Projucer to 10.8 but this didn’t carry over to XCode and it instead was 10.9

Just picked up a new arm machine and with Xcode 12.2 I’m finding Time Profiler will not show symbols for DemoRunner (and my own app). If I go to Instruments -> File -> Symbols -> Expand “DemoRunner” is says “Permission to profile this process was denied. Applications you wish to profile must be signed with a developer code”. Changing signing options however doesn’t seem to have any effect. For testing sake I created a blank swift project in Xcode and that had no issues with symbols despite having no code signing options set. Wondering if anyone’s seen this. Searching google for that error message brings up zero results.

1 Like

I found this and had to put set my signing ID in the xcode exporter settings in projucer. Works fine now for testing.

1 Like

Thanks, that indeed seems to fix it! I’m using cmake so I used the instructions in the CMake api doc to add the code sign identity and development team. I couldn’t figure out how to apply them to the DemoRunner but I followed the instructions for building the basic GUI app and that worked.

I must say it’s still strange that changing these settings in Xcode isn’t enough. And it’s also strange that creating a project in Xcode (and downloading one from apple’s dev site) happily profile without the need for this. My guess would be that there’s something configured wrong in the JUCE generated projects. Or maybe Apple is giving preferential abilities for it’s own project files or something? That’s probably far-fetched but who knows.

I double checked on my other machine using the same test setup (Cmake GuiApp example) and confirmed that the signing information is not required for profiling with that setup.

Machine 1 (no signing required) : intel, Catelina 10.15.6, Xcode 12.1
Machine 2 (signing required): m1, Big Sur 11.0.1, Xcode 12.2

Both machines used current JUCE master with CMake 3.19.1

I’ve now discovered that changing anything in the project file from within Xcode will cause Instruments to stop showing the symbols again. Between this and swift projects not requiring signing I think I’ll chalk this all up to bugs in Xcode.

@ graeme-2 how did you get cmake to with juce ?

Im having issues with juceadie compiling, it appears to be assuming mac are intel?

Ive got cmake (from homebrew) building my other cmake native projects successfully… but juce is throwing errors.


FIXED: needed to pull new version of juce - thanks @reuk for the info

another small issue…

I created universal binaries for vst2 and vst3.
both show up in AudioPluginHost without issue.

however, Intel hosts specically Ableton Live 11 (beta)/Bitwig 3.3 , only the vst3 shows up. neither show the VST2 … if I do file on the vst2, it shows both the arm and x86 build.

note: this is using cmake, but not sure if this is relevant or not.

Has anyone been able to profile an ARM release build and see per line performance metrics in your source code? I have set up my signing ID in projucer, disabled Strip Local Symbols, and added the suggested Xcode flags, but when profiling via Instruments I’m only able to see the machine code, not the C++.

@DavidCNAntonia, @graeme-2 - does this work for you?

Hi ericsen. Sorry, I ended up returning the M1 so I don’t know anything more about the issue.

1 Like

i don’t have an ARM but i’ve noticed that on my (intel) mac when i select “profile” from xcode the first run never has symbols. i have to stop it in instruments, go back to xcode, then “profile without building”, then i get symbols.

Thanks, but the “Profile without building” is greyed out here. I am getting symbols though, I’m just not able to dig into the source code too see exactly where bottlenecks might be. However, it seems it’s not ARM specific. I am able to do this in Visual Studio and on my older Mac/Xcode, but on BigSur/Xcode12 I can’t get it to show on neither Intel or Apple Silicon builds.

As I’m barely one level above moron I might be missing something obvious, but I’m wondering if anyone is able to get “per line” profiling to work on BigSur/Xcode12?

Would you elaborate on the lines you added to patch the AAX SDK? Could you post a git gist somewhere?