Thanks Greg for your suggestions.

But I found something from
https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BPF
rameworks/Concepts/WeakLinking.html
I have tried the way mentioned in that, so passed "-weak_framework Appkit²
in Other Linker Flags under Build Settings of the framework(X.framework)
target. It worked on 10.5 and 10.6 as well.


Greg, as its working in the above approach, I can go ahead with it instead
of having separate bundle/plugin/library, then loading it after OS
validation.. Etc.
Can you put some light on it and any thoughts on the final approach.


Thanks,
Satya



On 11/8/14, 12:14 AM, "Greg Parker" <gpar...@apple.com> wrote:

>
>> On Nov 7, 2014, at 3:54 AM, Satyanarayana Chebrolu
>><satyanaraya...@ivycomptech.com> wrote:
>>
>> Hi folks,
>> We have an application, which is supporting from 10.5(Leopard) to
>>10.10(Yosemite). Inside the application, there is  a  custom
>>framework(X.framework), which has some custom code for Appkit classes.
>> Off late, decided to introduce a new feature, which will be supported
>>from 10.7 to 10.10. And then subclassed the classes (NSTableRowView,
>>NSTableCellView), which are part of the X.framework.
>>
>> Problem:
>> The app is getting crashed when we launch it on 10.5 and 10.6 machines
>>saying that “dyld: Symbol not found: _OBJC_CLASS_$_NSTableCellView”.
>>
>> Understand that NSTableRowView, NSTableCellView are not existing on
>>10.5 and 10.6, so the subclasses should be weakly linked.
>
>Weak import of Objective-C symbols does not work on 10.5 and 10.6. The
>runtime support for it was introduced in 10.6.8.
>
>One solution is to drop support for OS versions older than 10.6.8.
>
>Another solution is to use dynamic framework loading to keep the code
>that uses NSTableCellView out of your process when the OS is too old. You
>would perform an OS version check and use NSBundle or dlopen to load your
>framework if the OS version is new enough. This works for anything.
>
>Another solution is to use NSClassFromString(@"NSTableCellView") and
>never access the class directly. This works for classes that you use but
>do not subclass; it does not work if you need to subclass a class.
>
>It is possible to create a subclass dynamically at runtime, after
>performing an OS version check. This is typically feasible only in simple
>cases.
>
>
>--
>Greg Parker     gpar...@apple.com     Runtime Wrangler
>
>

This email and any attachments are confidential, and may be legally privileged 
and protected by copyright. If you are not the intended recipient dissemination 
or copying of this email is prohibited. If you have received this in error, 
please notify the sender by replying by email and then delete the email 
completely from your system. Any views or opinions are solely those of the 
sender. This communication is not intended to form a binding contract unless 
expressly indicated to the contrary and properly authorised. Any actions taken 
on the basis of this email are at the recipient's own risk.

_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to