Thanks to everyone for their suggestions, particularly Greg Parker for the unambiguous clarification.
While the safest approach is to use NSClassFromString to ensure that you can run in 64 bit on 10.5, I opted not to do that because it's not enough to actually get all 64-bit apps to work on 10.5, and it also has the downside of essentially requiring frequent testing on 10.5 Intel to make sure you didn't forget something - I'm not big on relying on humans to prevent errors, especially me. In my info,plist I force Leopard to run in 32 bit: LSMinimumSystemVersionByArchitecture x86_64 10.6.0 which results in everything running fine on all platforms, and solves an issue involving System Configuration as well: The issue involves the System Configuration and IOKit frameworks. If you use attempt to use certain functions from the System Configuration Framework in a x86_64 application on 10.5.8, you will get this crash report: ----- Date/Time: 2010-03-09 16:37:05.849 -0800 OS Version: Mac OS X 10.5.8 (9L31a) Report Version: 6 Anonymous UUID: 27FDECB3-E71F-4ED5-9E76-49DA5B513E3E Exception Type: EXC_BREAKPOINT (SIGTRAP) Exception Codes: 0x0000000000000002, 0x0000000000000000 Crashed Thread: 0 Dyld Error Message: Symbol not found: _SCDynamicStoreCreate Referenced from: /Users/smykytyn/Desktop/TEST.app/Contents/MacOS/TEST Expected in: /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit ---- If you do an "nm" on the System Configuration and IOKit frameworks in the 10.5 and 10.6 SDKs, you will see that some SCF functions in the 10.6 SDK are shown in both frameworks, but not in 10.5 IOKit: Last login: Wed Mar 10 08:39:27 on console SM-MBP:~ smykytyn$ nm /Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/IOKit.framework/IOKit | grep Dynamic SM-MBP:~ smykytyn$ nm /Developer/SDKs/MacOSX10.6.sdk/System/Library/Frameworks/IOKit.framework/IOKit | grep Dynamic 000000000001f47f T _SCDynamicStoreCopyMultiple 000000000001f422 T _SCDynamicStoreCopyValue 000000000001f39d T _SCDynamicStoreCreate 000000000001f330 T _SCDynamicStoreCreateRunLoopSource 000000000001f582 T _SCDynamicStoreKeyCreate 000000000001f2c5 T _SCDynamicStoreKeyCreatePreferences 000000000001f1af T _SCDynamicStoreNotifyValue 000000000001f264 T _SCDynamicStoreSetNotificationKeys 000000000001f203 T _SCDynamicStoreSetValue The Growl people had an obscure reference to this about building for 64-bit using the 10.5 SDK as their workaround, although I can't find it right now. Perhaps there is some magic obvious solution to get all this to work correctly, but for now I'm restricting Leopard to 32-bit as I need to use these things. On Mar 9, 2010, at 3:25 PM, Greg Parker wrote: > On Mar 9, 2010, at 2:57 PM, Steve Mykytyn wrote: >> I know all about separating 10.6 from 10.5 stuff. The problem is: I've been >> testing on a 10.5 PPC machine, where everything works fine. On 10.5 Intel, >> it does not finish starting up, just crashes out. Never gets anywhere that >> I would use something 10.6 related. >> >> Trying to be as clear as possible: >> >> 10.6 Intel Snow Leopard - works fine >> 10.5 Intel Leopard - crashes complaining about NSRunningApplication >> 10.5 PPC Leopard - works fine >> >> Even if the startup sequence for an app was different between PPC and Intel, >> I'd expect to eventually crash out on both PPC and Intel if it was something >> I'm doing in the source code. > > I'm guessing that you crash on 10.5/Intel/Leopard/64-bit and do not crash on > 10.5/Intel/Leopard/32-bit. > > If you write anything like this and run on a system where the class is not > present, you will crash on 64-bit but may or may not crash on 32-bit: > > // BAD > [NSRunningApplication someMethod]; > > If NSRunningApplication may be absent at runtime, then you must not refer to > it directly, ever. You must use NSClassFromString() everywhere: > > // GOOD > Class nsRunningApplicationClass = > NSClassFromString(@"NSRunningApplication"); > [nsRunningApplicationClass someMethod]; > > > -- > 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
