Re: Weak linking
That approach is not supported and will crash at runtime in some circumstances. Nobody has tried to make a list of precisely which cases will and will not work, so you're on your own here. For example, if you code has a category on NSTableCellView then it will crash. If your subclass of NSTableCellView has a +load method then it will probably crash. If you call [MyNSTableCellView class] then it might crash. Et cetera. > On Nov 8, 2014, at 10:09 AM, Satyanarayana Chebrolu > wrote: > > 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. > > Attached a screenshot for the same. > > Greg, as its working in the above approach, I can go ahead with it instead > of having separate bundle, 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" wrote: > >> >>> On Nov 7, 2014, at 3:54 AM, Satyanarayana Chebrolu >>> 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
Re: Weak linking
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" wrote: > >> On Nov 7, 2014, at 3:54 AM, Satyanarayana Chebrolu >> 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
Re: Weak linking
> On Nov 7, 2014, at 3:54 AM, Satyanarayana Chebrolu > 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 ___ 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
Re: Weak linking
Yes, its 10.5 only. On 11/7/14, 9:46 PM, "Fritz Anderson" wrote: > >On Nov 7, 2014, at 5:54 AM, Satyanarayana Chebrolu > wrote (slightly more appropriate to >xcode-users): >> >> 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. >> >> Tried, by making Cocoa & X.frameworks as Weak linking(Optional) under >>Link Binary With Libraries section of the application target, but still >>the same issue. It seems, I am missing something. > >Have you set the ³Deployment Target² (most easily found under the General >tab in the Target editor) to 10.5? > > ‹ F > > 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
Re: Weak linking
On Nov 7, 2014, at 5:54 AM, Satyanarayana Chebrolu wrote (slightly more appropriate to xcode-users): > > 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. > > Tried, by making Cocoa & X.frameworks as Weak linking(Optional) under Link > Binary With Libraries section of the application target, but still the same > issue. It seems, I am missing something. Have you set the “Deployment Target” (most easily found under the General tab in the Target editor) to 10.5? — F ___ 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
Weak linking
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. Tried, by making Cocoa & X.frameworks as Weak linking(Optional) under Link Binary With Libraries section of the application target, but still the same issue. It seems, I am missing something. Should be a straight way to fix it. Will be great if you can share your thoughts. I am using Xcode 6.1. Thanks in advance. -Satya 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
Re: Weak-linking a class
See also < http://www.sealiesoftware.com/blog/archive/2009/09/09/objc_explain_Weak-import_classes.html >. -Ken On Sun, Jun 27, 2010 at 7:02 AM, Graham Cox wrote: > > On 27/06/2010, at 11:55 PM, Andy Lee wrote: > > > NSClassFromString()? Or maybe some objc_xxx runtime function? > > > > --Andy > > > D'oh, of course. Just tired... ;-) > > --Graham > > > ___ > > 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: > http://lists.apple.com/mailman/options/cocoa-dev/kenferry%40gmail.com > > This email sent to kenfe...@gmail.com > ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Weak-linking a class
On 27/06/2010, at 11:55 PM, Andy Lee wrote: > NSClassFromString()? Or maybe some objc_xxx runtime function? > > --Andy D'oh, of course. Just tired... ;-) --Graham ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Weak-linking a class
NSClassFromString()? Or maybe some objc_xxx runtime function?
--Andy
On Jun 27, 2010, at 9:50 AM, Graham Cox wrote:
> How do I test for the existence of a Cocoa class at runtime that could be
> absent on an earlier system?
>
> The situation is that I want to use NSCache instead of NSMutableDictionary
> somewhere. The object is created as a singleton when it's first used, but I
> can't quite see how I should decide which class to make. I've read the
> weak-linking guide and it makes sense, but the example in there shows only a
> simple C function, not an Obj-C class.
>
> I'm setting 10.6 SDK as my base SDK, but my minimum deployment target is
> 10.5. Therefore NSCache will not be there on 10.5.
>
> I thought I could do e.g.:
>
> if([NSCache alloc] == nil ){ ... fall back to NSMutableDictionary ... }
>
> but on 10.6 that actually calls [NSCache alloc] which I don't want, I just
> want to test whether [NSCache alloc] (or any appropriate class method)
> actually exists or not, or more precisely, whether NSCache exists. I'm
> guessing it's easy and probably obvious when you know it, but I'm not seeing
> it.
>
> --Graham
>
>
>
>
> ___
>
> 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:
> http://lists.apple.com/mailman/options/cocoa-dev/aglee%40mac.com
>
> This email sent to ag...@mac.com
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Weak-linking a class
How do I test for the existence of a Cocoa class at runtime that could be
absent on an earlier system?
The situation is that I want to use NSCache instead of NSMutableDictionary
somewhere. The object is created as a singleton when it's first used, but I
can't quite see how I should decide which class to make. I've read the
weak-linking guide and it makes sense, but the example in there shows only a
simple C function, not an Obj-C class.
I'm setting 10.6 SDK as my base SDK, but my minimum deployment target is 10.5.
Therefore NSCache will not be there on 10.5.
I thought I could do e.g.:
if([NSCache alloc] == nil ){ ... fall back to NSMutableDictionary ... }
but on 10.6 that actually calls [NSCache alloc] which I don't want, I just want
to test whether [NSCache alloc] (or any appropriate class method) actually
exists or not, or more precisely, whether NSCache exists. I'm guessing it's
easy and probably obvious when you know it, but I'm not seeing it.
--Graham
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Weak Linking Crash
Il giorno Mar 11, 2009, alle ore 6:22 PM, Greg Parker ha scritto:
-weak_framework often doesn't work by itself. If the function
declaration isn't marked weak_import in the header file, then the
compiler may optimize out your `function != NULL` check and call the
weak-linked function anyway.
This workaround might help defeat the optimizer:
// was: if (&function != NULL) function();
void * volatile function_p = &function;
if (function_p != NULL) function();
OK, this seems to be the case. I found that the code that Apple
suggests in its Weak Linking documentation to just not work. Even
when *un*optimized, the compiler seems to always think the comparison
in the if statement of the following code is true.
int result = 0;
if (MyWeakLinkedFunction != NULL)
{
result = MyWeakLinkedFunction();
}
I have been using the following syntax:
int result = 0;
uintptr_t address = (uintptr_t)(MyWeakLinkedFunction);
if (address != 0u)
{
result = MyWeakLinkedFunction();
}
The compiler likes this when *un*optimized, but it looks like the
compiler is optimizing this out, too. I found that when using your
code, however, that I needed to explicitly cast the function as a
void* before the compiler would build without errors:
void * volatile function_p = (void *)&(MyWeakLinkedFunction);
if (function_p == NULL) {
result = MyWeakLinkedFunction();
}
Thanks for your help! That solved the problem!
-- Simone
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Weak Linking Crash
On Mar 11, 2009, at 5:47 PM, Simone Manganelli wrote:
So I'm trying to weak link the SDL_mixer framework (svn source
avaliable here: http://svn.libsdl.org/trunk/SDL_mixer ) to a Cocoa
project, the Mac OS X port of Descent 2 (svn source available here: https://d2x-xl.svn.sourceforge.net/svnroot/d2x-xl
).
I've followed the instructions on Apple's website about weak linking
(see http://developer.apple.com/DOCUMENTATION/MacOSX/Conceptual/BPFrameworks/Concepts/WeakLinking.html
). Specifically, I've added "-weak_framework SDL_mixer" in my
Other Linker Flags build setting.
Here's the problem: weak linking works well under *unoptimized*
builds, but fails in *optimized* builds. The program launches
correctly both with and without SDL_mixer present when unoptimized.
However, as soon as I turn on optimization, the program crashes when
the SDL_mixer framework is not present. The optimized build
continues to work fine when the SDL_mixer framework *is* present.
Since I'm shipping an optimized version, weak linking in this case
is useless, because it provides no benefit over not weak linking.
The program simply crashes if SDL_mixer is not present, no matter if
it has been weak linked or not.
The crash seems to occur *before* any code in my application; it
crashes when trying to send an appDidFinishLaunching notification.
Here is a partial stack trace:
Thread 0 Crashed:
0 ??? 00 0 + 0
1 de.descent2.d2x-xl 0x0008bda3 0x1000 + 568739
2 de.descent2.d2x-xl 0x0008f7ed 0x1000 + 583661
3 de.descent2.d2x-xl 0x0008fb9c 0x1000 + 584604
4 de.descent2.d2x-xl 0x00057fc3 0x1000 + 356291
5 com.apple.Foundation0x90b53f1c _nsnote_callback + 364
6 com.apple.CoreFoundation 0x93ea38da __CFXNotificationPost
+ 362
7 com.apple.CoreFoundation 0x93ea3bb3
_CFXNotificationPostNotification + 179
8 com.apple.Foundation 0x90b51080 -
[NSNotificationCenter postNotificationName:object:userInfo:] + 128
Those top few frames sure look like they're in your code
("de.descent2.d2x-xl"). Try running an unstripped Release build to get
a better backtrace.
It looks like it crashed because it called a NULL function pointer,
because the PC is zero. That's consistent with either "you called a
weak-linked function without checking for NULL first" or "compiler
optimized away your NULL check". The fact that an unoptimized build
works suggests the latter, but you should find the bad call and check
for sure.
-weak_framework often doesn't work by itself. If the function
declaration isn't marked weak_import in the header file, then the
compiler may optimize out your `function != NULL` check and call the
weak-linked function anyway.
This workaround might help defeat the optimizer:
// was: if (&function != NULL) function();
void * volatile function_p = &function;
if (function_p != NULL) function();
--
Greg Parker gpar...@apple.com Runtime Wrangler
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Weak Linking Crash
So I'm trying to weak link the SDL_mixer framework (svn source avaliable here: http://svn.libsdl.org/trunk/SDL_mixer ) to a Cocoa project, the Mac OS X port of Descent 2 (svn source available here: https://d2x-xl.svn.sourceforge.net/svnroot/d2x-xl ). I've followed the instructions on Apple's website about weak linking (see http://developer.apple.com/DOCUMENTATION/MacOSX/Conceptual/BPFrameworks/Concepts/WeakLinking.html ). Specifically, I've added "-weak_framework SDL_mixer" in my Other Linker Flags build setting. Here's the problem: weak linking works well under *unoptimized* builds, but fails in *optimized* builds. The program launches correctly both with and without SDL_mixer present when unoptimized. However, as soon as I turn on optimization, the program crashes when the SDL_mixer framework is not present. The optimized build continues to work fine when the SDL_mixer framework *is* present. Since I'm shipping an optimized version, weak linking in this case is useless, because it provides no benefit over not weak linking. The program simply crashes if SDL_mixer is not present, no matter if it has been weak linked or not. The crash seems to occur *before* any code in my application; it crashes when trying to send an appDidFinishLaunching notification. Here is a partial stack trace: Thread 0 Crashed: 0 ??? 00 0 + 0 1 de.descent2.d2x-xl 0x0008bda3 0x1000 + 568739 2 de.descent2.d2x-xl 0x0008f7ed 0x1000 + 583661 3 de.descent2.d2x-xl 0x0008fb9c 0x1000 + 584604 4 de.descent2.d2x-xl 0x00057fc3 0x1000 + 356291 5 com.apple.Foundation0x90b53f1c _nsnote_callback + 364 6 com.apple.CoreFoundation 0x93ea38da __CFXNotificationPost + 362 7 com.apple.CoreFoundation 0x93ea3bb3 _CFXNotificationPostNotification + 179 8 com.apple.Foundation 0x90b51080 -[NSNotificationCenter postNotificationName:object:userInfo:] + 128 9 com.apple.Foundation 0x90b5a8c8 -[NSNotificationCenter postNotificationName:object:] + 56 10 com.apple.AppKit 0x91c8f49a -[NSApplication _postDidFinishNotification] + 125 11 com.apple.AppKit 0x91c8f3a9 -[NSApplication _sendFinishLaunchingNotification] + 77 12 com.apple.AppKit 0x91c08ec3 - [NSApplication(NSAppleEventHandling) _handleAEOpen:] + 284 13 com.apple.AppKit 0x91c086bc - [NSApplication(NSAppleEventHandling) _handleCoreEvent:withReplyEvent:] + 98 14 com.apple.Foundation 0x90b7943f -[NSAppleEventManager dispatchRawAppleEvent:withRawReply:handlerRefCon:] + 655 15 com.apple.Foundation 0x90b7914f _NSAppleEventManagerGenericHandler + 223 16 com.apple.AE 0x916b1648 aeDispatchAppleEvent(AEDesc const*, AEDesc*, unsigned long, unsigned char*) + 144 17 com.apple.AE 0x916b157e dispatchEventAndSendReply(AEDesc const*, AEDesc*) + 44 The whole crash report can be found here: http://homepage.mac.com/simx/weak_linking_crash_log.txt . Anybody know what's going on here and how to solve it? The intarwebs and the Googles don't seem to be providing anything relevant. Thanks in advance for any assistance. -- Simone ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Weak Linking & using HiShape
On Tue, Sep 2, 2008 at 8:38 AM, Eric Schlegel <[EMAIL PROTECTED]> wrote: > I believe the problem was also fixed in Xcode 3.1, so you might also be able > to install 3.1 and associated SDKs and link against the 10.5 SDK in that > release. It must be because our product isn't bitten by this issue and we first picked up the 10.5 SDK on the switch over to Xcode 3.1 (the total of our HIShape code is wrapped to only exist when the 10.5 SDK is available). -Shawn ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Weak Linking & using HiShape
On Sep 2, 2008, at 5:06 AM, Pierre Guilluy wrote: After recompiling the libraries and minimal example using -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.4 the example works fine under 10.5 but running it under a 10.4 system comes with a dyld error dyld: lazy symbol binding failed: Symbol not found: _HIShapeCreateWithRect How can I do to solve a problem like this and have an application that uses weak linking and works on both platforms ? This is due to a configuration error when the HIServices and HIToolbox libraries were built in Leopard. You're doing basically the right thing, but the HIShape symbols moved from the HIToolbox framework to the HIServices framework in Leopard and when you link on Leopard (even when setting the min Mac OS X version to 10.4), the linker resolves the symbol locations to HIServices and stores that as the path to the symbol, which fails on 10.4 where the symbols are actually located in HIToolbox. We fixed the problem in HIToolbox and HIServices around 10.5.3, so one possibility is to build on 10.5.3 or 10.5.4 and in your SDK setting, link against Current Mac OS rather than 10.5 SDK. I believe the problem was also fixed in Xcode 3.1, so you might also be able to install 3.1 and associated SDKs and link against the 10.5 SDK in that release. -eric ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Weak Linking & using HiShape
Hi there, We're trying to compile our application so that it can run under 10.5 & 10.4 using weak linking (this is required for us other libraries). Our software is based on wxWidget and so for the moment we're evaluating the possibility of running the minimal sample from wxWidget using weak linking. After recompiling the libraries and minimal example using -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.4 the example works fine under 10.5 but running it under a 10.4 system comes with a dyld error dyld: lazy symbol binding failed: Symbol not found: _HIShapeCreateWithRect The strange thing was that using gdb, I could successfully put a breakpoint in the 'missing' function and it would work everytime it's called internally by another Framework but then fail when called from the wxWidget libs. Finally I discovered that the error is coming not because the symbol doesn't exist but because it's been moved from 10.4 to 10.5: Under 10.4 HIShape.h was part of Carbon, while now it's part of ApplicationServices. How can I do to solve a problem like this and have an application that uses weak linking and works on both platforms ? Thanks Marc. ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: weak linking
On 30 Mar 2008, at 01:47, [EMAIL PROTECTED] wrote:
I use in some Cocoa app a weak linked library.
[...]
if (weak_function == NULL)
{
NSLog(@"%s weak_function %p NULL", __FUNCTION__, weak_function );
}
else
{
NSLog(@"%s weak_function %p non-NULL", __FUNCTION__, weak_function );
}
The result without library is:
... weak_function 0x0 non-NULL
10.4.11, powerpc-apple-darwin8-gcc-4.0.1.
Without this line:
extern void weak_function() __attribute__((weak_import));
the compiler notices that weak_function is non-NULL during
compilation and optimizes under the assumption that it will remain
non-NULL even at run time.
Kind regards,
Gerriet.
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
weak linking
I use in some Cocoa app a weak linked library.
In some class I do:
- (BOO)haveNoLibrary
{
BOOL noHave1 = weak_function == NULL ; // does NOT work - is
always NO
void *dummy = weak_function;
BOOL noHave2 = dummy == NULL ; // does work - is YES if and only
library is missing
return noHave2;
}
Why is noHave1 always NO?
Next I copied some code from the Framework Programming Guide -
Frameworks and Weak Linking:
if (weak_function == NULL)
{
NSLog(@"%s weak_function %p NULL", __FUNCTION__, weak_function );
}
else
{
NSLog(@"%s weak_function %p non-NULL", __FUNCTION__, weak_function );
}
The result without library is:
... weak_function 0x0 non-NULL
10.4.11, powerpc-apple-darwin8-gcc-4.0.1. weak_function returns void.
Kind regards,
Gerriet.
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
weak linking of ImageKit framework
I am developing an app that should run on Tiger as well as Leopard. I want to use IKSlideshow when running on Leopard, so I wrote a class (let's call it MyDataSource) that implements the methods of IKSlideshowDataSource, which is instantiated in the method that will start the slideshow. This method is only called if the app is running on Leopard. In the build settings I set the SDK to 10.5 and the Deployment Target to 10.4. I also added the linker flag -weak_framework ImageKit. Now, when I am compiling the project, I get a warning "Mac OS X 10.5 or later is needed for use of property" wherever MyDataSource.h is included. Since I don't currently have a Tiger system at hand for testing, I was wondering, whether the app will run on Tiger anyway or whether there is something else I need to do. Thanks, Daniel ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
