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.
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.
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)
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:
“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.
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)
“Note that the following files appeared to be plugin files, but failed to load correctly: aumu,Jvfw,Manu”
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.
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?
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.
