On 22 Jun 2015, at 08:38, Nick Blievers < email@hidden> wrote:
On 22 Jun 2015, at 10:32 am, Quincey Morris < email@hidden> wrote:
On Jun 21, 2015, at 16:07 , Nick Blievers < email@hidden> wrote:
To avoid this you need to use something like NSClassFromString, so that all references to the object are dynamic.
I think this is not the complete story. Automatic weak linking of frameworks works for OS X now, and my vague recollection is that it was introduced mid-major-version of OS X, perhaps at 10.6.8. (Again I don’t recall, but it may have only been introduced for the new non-fragile ABI, which is probably why the 32-bit version has different behavior.)
Therefore, it’s possible that setting the deployment target to 10.6.8 will resolve the issue, assuming Xcode knows what it’s doing. (Of course, that cuts the app off from earlier 10.6 users, but so much changed and got fixed at 10.6.8, that these users really ought to have upgraded.) Alternatively, manually forcing the framework to be weak-linked might allow the current code to work back to 10.6.0.
But this isn’t a framework weak link - it should just be a symbol weak link. That symbol has the availability macro on it, so it should be in the binary as weak as long as the target is, as Scott said earlier, set to pre-10.7. But if the deployment target is 10.7, that information should be in the binary as well and it should fail to load at all, usually with a very cryptic error message. Not making much sense.
Is there a stack trace here at all or is this really failing before any code is run? The only other thing I could think of is an NSDataDetector in a NIB, created by some visual component.
|