MacOS 10.9.5 - "Symbol not found: _OBJC_CLASS_$_NSMutableURLRequest”

Hello,

I’ve upgraded our products to JUCE 6 and just ran into a new issue with our Registration utility app on MacOS 10.9.5. See image below.

The only thing I can find online about that error relates to IOS Swift apps.

1 Like

We’re also able to reproduce this with one of our products.

@ComposerShield what Xcode did you use to build it?

2 Likes

It was Xcode12 Beta.

It actually seems to be happening with many of our products now…with different “OBJC_CLASS” symbols missing.

1 Like

We’ve tested this for sanity. On our macOS 10.8 test machine, a build from the exact same commit (of JUCE and our product) crashes when build with Xcode 12.2 / macOS 10.5.7, works when build using Xcode 11 on Mojave.

We’ll investigate. I’ll try making a JUCE demo project to reproduce this with bare minimal.

2 Likes

I don’t think it has anything to do with JUCE. I asked around on the Apple Developer Forum and other people ran into the same issues. It’s an Xcode12 thing. It might be time for us to not support 10.5 and earlier anymore…

We’ve found the issue.
As suggested by several stackoverflow threads it’s related indeed to what the crash suggest.
It might be Foundation.framework missing or an ordering issue.
Seems like Apple dropped ‘defaulting’ Foundation inclusion.

A fix:
Add to Projucer Extra System Frameworks the “Foundation” (framework) and you’re all set.

To avoid mentioning JUCE team in the forum. I’ve opened a github issue as this seems very trivial fix.


(I can do a PR but I guess it’ll be less noisy for JUCE team to simply commit this small fix themselves).
3 Likes

How do you compile for Mac OS X 10.8 using Xcode 12.2? The min supported sdk target is 10.9.

We were skeptic at first, but we do our best to support our users even on older machines :slight_smile:

Xcode 12.1 - Deployment target goes down to 10.6.
Xcode 12.2 - Deployment target goes down to 10.9.

JUCE allows you to set it to 10.7 and it DOES seem to work. (we only tested up to 10.8 since that was the fastest for us)
(you can also on non-juce project manually input deployment target…)

2 Likes

Awesome. Thanks!

Even it it may work right now I don’t think it is wise to build for anything below the min target Apple supports. Compatibility might break with any update to XCode in the future as clearly Apple does not care about it.

In my testing I also found that installer signing broke for older versions of OS X. If I sign my installer on Big Sur, it cannot launch on 10.7. If I sign it on 10.13 it is still ok. But as I wasn’t able to build for 10.7 myself I decided to just go with Apple on this one and raise my min requirements to 10.9 - any of their tools might break for <10.9 at any time.

Any of their tools might break for any OS version at any time, so by this logic why even support their platform at all? I say: test. If it breaks, and the specific version isn’t worth your effort, then you can drop it. For me, if it’s just a small setting to make it work, and it does work, and I still have users on those systems, why not support it?

2 Likes

This is interesting. Can you run otool -L on both the binaries (the broken one built with Xcode 12.2 and the one built with an older Xcode) and post the output? It’d be useful to see if perhaps the include order of the frameworks has changed. It might be similar to this AudioUnit issue:

1 Like

I couldn’t glean any useful information using otool on binaries built with the latest Xcode beta and an older version, it looks like the frameworks are linked in the same order. We’ve added the fix proposed above to explicitly add Foundation as an OSXFrameworks dependency in juce_core:

3 Likes

No, because in this case if it breaks Apple won’t fix it and you’ll have the choice to either not update your XCode or break compatibility. But don’t get me wrong, I have absolutely nothing against you supporting 10.7. For me there are definitely enough things to test without going outside the officially supported systems. If you never raise your min requirements, your testing workload is going to keep rising - and you have to keep the old systems/hardware around.

In the meantime I tested the fix and it does work for me. So unofficially my stuff will maybe still run on 10.7. However I still couldn’t figure out how to sign my installer on Big Sur. I am using the Packages.app software to sign the installer. Using the same certificate I loose compatibility with older versions of OS X if I sign on OSX 11 vs OSX 10.13.6. Has anyone found a workaround around this?

When I launch the installer I get “…can’t be installed because its digital signature is invalid.”

1 Like

Update: the installer signing problem is discussed on another thread and is related to the productsign command used by Packages.app: