I fired up ReceiptWallet beta on a Tiger machine today to check out a problem and it didn’t launch. Huh, I looked at the crash log and it said there was a problem with a symbol not found using the dynamic linker (I’m not sure why my testers on Tiger didn’t find this as it clearly doesn’t work). So, I look at my code and I have:
[pictureTaker setValue:[NSNumber numberWithBool:NO] forKey: IKPictureTakerAllowsFileChoosingKey];
This code only executes on Leopard, so it should be fine. However, whoever decided to define this constant decided to define it as such:
extern NSString *const IKPictureTakerAllowsFileChoosingKey;
instead of something smart like:
#define IKPictureTakerAllowsFileChoosingKey @"IKPictureTakerAllowsFileChoosingKey"
Why is the second one smarter? Because it allows people to compile in features that work on 10.5 while still supporting 10.4. I have checks in my code to not execute this chunk of code on Leopard, so that isn’t a problem. The problem with this is that while everything compiles and links, it crashes on Tiger.
Apple wants us to use new technology, but most of us can’t abandon Tiger users, so we compile against the 10.5 SDK with a Mac OS X Deployment Target of 10.4 as indicated we should do in the Core Data Release Notes.
Apple, please fix this!
While it would be nice if ImageKit had the availability macros in the headers (and it will someday need them – probably best to file a bug), since ImageKit doesn’t exist at all on Tiger weak linking the entire framework should solve your problem.
How do I explicitly weak link ImageKit? I link Quartz which gets me ImageKit. So I don’t directly link in ImageKit. Should I weak link Quartz?
I forgot that ImageKit was part of an umbrella. If the -weak_framework doesn\’t solve the problem, perhaps someone on Xcode-users can offer advice.
Nope, -weak_framework Quartz doesn’t fix the issue. Oh well, I can either not use the 2 flags I use (they’re not all that important) or I can just hard code them for now.