Plug-in built with Xcode 11 fails to load on Yosemite (10.10)

as per title, when e.g. I try to auval it on a Yosemite machine, I get the following:

2019-10-29 17:37:49.062 auvaltool[25543:10647648] 17:37:49.062 ERROR:     >compload>
AudioComponentPluginLoader.cpp:513: ResolveFactoryFunction: 
CFBundle 0x7fd8a84187b0 </Library/Audio/Plug-Ins/Components/TestProject.component> (bundle, not loaded): 
cannot load bundle: The bundle "Test" couldn't be loaded.
FATAL ERROR: OpenAComponent: result: -1,0xFFFFFFFF

the plug-in was built on macOS 10.14 using Xcode 11.1 (the latest at the moment of writing).

There are two more odd thing:

  • the stand-alone app of the same project, also built with Xcode 11.1 runs without problems on Yosemite
  • the same project, built with Xcode 10.3, on the same machine with the same macOS version, results in a plug-in that run without problems on Yosemite.

So, the problematic combinations seems to be plug-in output + Xcode 11.1.

All previously mentioned builds have been done with

  • libc++ with C++11 support
  • 10.7 as Deployment Target. Changing it to 10.9 or even 10.10 didn’t make any difference in the outcome

Ideas?

2 Likes

I forgot to specify, that it all was built with JUCE 5.4.4

What if you use Xcode 11 but build against an older SDK?

Thank you for the links, I’m familiar with that technique.

Here the results:

Xcode 10.3 with SDK 10.14 (the default in Xcode 10.3): success
Xcode 11.1 with SDK 10.14 (copied from Xcode 10.3): success
Xcode 11.1 with SDK 10.15 (the default in Xcode 11.1): fail

It appears that the cause is the usage of SDK 10.15, but I don’t know how to debug this issue further, the plug-in simply refuses to load, therefore it’s even impossible to gather useful info from a Crash Report.

I have run “nm” on the binaries built for all the above combination, and they all exactly the same symbols with the exception of one, shown below, but that doesn’t seem to be the culprit because it’s present in both Xcode 11 builds, and the one in the middle is the one that works even if it has it.

1 Like

I received a report that our plugin built with 11.1 and 10.15 SDK does not validate with auval on OSX 10.9. I will report if i know more details.

1 Like

I can reproduce the auval issue on 10.10. I’m looking into it now.

3 Likes

I wondered whether the issue could be caused by the usage of some ObjC function not available in 10.10 and earlier.

Turns out there’s a way to make Xcode emit warnings if that’s the case (the meaningful part is in the comments to the linked StackOverflow answer):

21

in the Build Settings for your project/target, set “Unguarded availability” to “Yes (All Versions)”.

If you want to set it in a xcconfig file, that translates to:
CLANG_WARN_UNGUARDED_AVAILABILITY = YES_AGGRESSIVE

Turns out that, in JUCE 5.4.4 at least, that warning triggers in a few places in the JUCE codebase, perhaps it’s worth checking them?
Honestly they don’t seem to be too promising because the reports are mostly for stuff unavailable on OSes prior to 10.10, thus they don’t seem to indicate potential problems with 10.10 itself.

Still, is it a good idea enable that warning by default for the future?

I built against target SDK 10.13 with XCode 11.1 and it resolved the validation crash as expected until a fix is available. Unfortunately i don’t have any test system anymore where i can reproduce the crash.

I tried compiling a couple of other projects, with the same result:

  • An Apple AU example project from an ancient CoreAudio SDK (TremoloUnit)
  • An iPlug2 example plug-in

I was hoping that one of them would work so we had something to compare against.

If it is of any help, I have noticed that the loading problem exists not only for AU, but for VST2 and VST3 too.

It’s as if using the 10.15 SDK cripples the binaries capabilities of being loaded as "shared libraries"on macOS 10.10.

Also, the same source code, built with Xcode 11.1 but with different SDKs (10.14 vs 10.15) results in binary files inside the product’s bundle that differ of less than 200 bytes in size, despite having been compiled with different SDKs.

In consideration of the fact that the resulting binaries are around 22 MB in size, I would have expected the change in SDK to have a more significant impact on their size for whatever reason (a slight change in implementation of a system function, or something like that)

How are you loading the plug-ins on 10.10? On my system the JUCE demo host and REAPER both load the VST and VST3 correctly.

Are you still talking about the plug-ins built with SDK 10.15 (the one that comes by default with Xcode 11), right?

Intrigued by your answer here, I have repeated the loading tests on macOS 10.10 using:

  • REAPER 5.984 (64 bit)
  • AudioPluginHost built with SDK 10.14
  • AudioPluginHost built with SDK 10.15

let it be noted that to build AudioPluginHost I set the deployment target to 10.10, because by default it is 10.11.

In the above hosts, I have tried loading my plugin in VST3 and AU formats, each built first with SDK 10.14 and then with SDK 10.15. (I’ve skipped VST2 because it seems I have built AudioPluginHost without support for loading that format).

Here is the table with the outcome:

outcome

  • Not seen”: REAPER does its scan on startup and ignores the plug-ins built with SDK 10.15 when they are installed.

  • Err. Message”: AudioPluginHost gives a message saying that it has been unable to load the given plug-in. Message is slightly different for VST3 and AU, but the essence is the same. Screenshots are attached.

  • Crash”: AudioPluginHost in those cases simply crashes. The crash log is attached, for just one of the cases, because a diff of the two doesn’t reveal any meaningful difference. The call stack shows that AudioPluginHost calls into the system, presumably to search for some symbol, and that ends up causing a crash.

loading AU sdk 10.14 in host sdk 10.15.txt (56.3 KB)

I’m using the latest develop commit on JUCE with:

  • AudioPluginDemo as the test plug-in only modified to include VST2
  • AudioPluginHost only modified to include VST2

Compiling using Xcode 11.0 (11A420) on macOS 10.14.6.

Running REAPER 5.984 (64 bit) on the 10.10 machine.

With results:

            10.14 plug-in           10.15 plug-in
            VST  VST3  AU           VST  VST3  AU
REAPER      OK   OK    OK           OK   OK    Not loaded
APH 10.14   OK   OK    OK           OK   OK    Failed scan (1)
APH 10.15   OK   OK    Crash (2)    OK   OK    Crash (2)
  1. “Note that the following files appeared to be plugin files, but failed to load correctly: aumu,Jvfw,Manu”
  2. The same backtrace as you. This crash happens irrespective of the presence of AudioPluginDemo.

So perhaps it depends on the contents of the plug-in. Do you get the same results using AudioPluginDemo?

Reproducing a VST loading failure would be most useful, as that is the simplest format.

I’ll try with AudioPluginDemo later today and report back with that.

You are correct, using the AudioPluginDemo my table resembles yours:

            10.14 plug-in      10.15 plug-in
            VST3  AU           VST3  AU
REAPER      OK    OK           OK    Not loaded
APH 10.14   OK    OK           OK    Failed scan (1)
APH 10.15   OK    Crash        OK    Crash (2)

I don’t think there is any point enabling the VST2 on my side as I expect it to also agree with your tests.

Regarding the fact that my plug-in also fails in VST3, I suspect that may be due to the fact that we’re still compiling it as an old-fashioned “multiformat” binary, that has entry points for all the formats in a single binary. (It has always worked so far, even with Catalina)

Possibly that circumstance causes the same issue that affects AU to creep into the other formats. Could be that a relevant information to debug the AU issue?

@t0m, have you found something interesting regarding this issue?

We’ve had our hands full organising ADC, so I’ve not had chance to investigate further.

Since hosting AUs on 10.0 is problematic when using the later SDK, irrespective of the plug-ins present, it seems like this would be the easiest way to learn more. My approach would be to simplify the plug-in loading code as much as possible until the scope is narrow enough to work out what’s amiss.

1 Like