I'm making an application that depends on webkit, with some modifications to the webkit code. Thus, I need to use a private framework. I've made the install path of the framework relative to the executable using the #executable_path directive.
On Snow Leopard, everything works perfectly. However, on OS X Lion, dyld loads the system webkit (the one used by Safari) in addition to my private framework. This extra load only happens after I right click on the WebView and select "Inspect Element." I would have to do some deeper debugging to figure out which import exactly is causing dyld to go hunting. In the build output, I see no indication of linking to the external webkit, so I'm at a loss as to why this is happening, especially since it worked on Snow Leopard.
I don't want to change the DYLD_LIBRARY_PATH environment variable as this application needs to be distributed to other machines - users should be able to just run the app.
I suppose I could change the name of the framework and see if that fixes the issue. I'll update this question with the result of investigating the symbol that causes dyld to go looking for the system webkit, as well as making the framework name unique, but any thoughts here would be helpful.
Related
I have an application in the Mac App Store. I'm trying to support users going back to Snow Leopard but this is becoming increasingly difficult.
Recently I've hit a roadblock due to the iTunesLibrary.framework, this framework must be linked to the main executable and yet doing so will always trigger a crash on load when running in Snow Leopard.
To workaround this problem, I want to compile a version of my app that doesn't use features and frameworks from newer versions of OSX. The problem is, how can I launch the compatibility build automatically?
I'm considering trying to make the main executable point to a shell script, but I don't really like that idea. I've also thought of the main executable being a helper that simply launches the full app and then exits. I expect this would work, but I worry about it getting approved by Apple. Finally, I'm wondering if the app bundle format itself can support this kind of setup, maybe via an advanced used of CFBundleExecutable that I'm unaware of.
Has anyone been down this road, what would you suggest?
Try weak linking the frameworks, more information about Weak Linking and Apple Frameworks here. Then also check in your code for the OS version or - (BOOL)respondsToSelector:(SEL)aSelector of any NSObject to determine what you can call and what not.
To have Snow Leopard as Base SDK you'll need an old Xcode and will have troubles submitting to Mac App Store.
I'm troubleshooting a crash that's happening deep in the WebKit framework (specifically in WebCore.framework). The cause of the crash is a known bug in WebKit. In order to work around it, I need to be able to figure out what DOM element WebKit is working with when it crashes. For that I need to inspect the local and stack variables in WebKit at the time of the crash.
I have a core dump, but of course no debug symbol table for WebKit.
Are these available anywhere?
I found the WebKit nightly builds page, but those appear to be released builds stripped of debug information,
My fallback plan is to download WebKit sources and build them myself with debug switches, but it'd be amazing if those debug binaries were already archived somewhere.
I contacted Apple technical support; they told me that no symbols for the Mountain Lion shipping version of WebCore.framework were available anywhere. Apple appears to have stopped providing debug libraries after OS X 10.5.
We wound up working around the problem by using DYLD_FRAMEWORK_PATH (reference) to load a non-buggy version of WebKit on the customer's machine.
I have a menu-bar based application, which displays a window, when the icon is clicked.
It all works fine on Mac OS X Lion, but for some reason, an error occurs on Snow Leopard an sooner versions of Mac OS X. Anytime [TheWindowController window] is called the method stops, but the app keeps running. Because of this, I don't think that the window is just nil, it's corrupt, in some way.
I have no Idea why this happens, and like I said, it only happens in Mac OS X Snow Leopard.
Btw. I use ARC, if that matters at all.
You're loading a NIB that uses a 10.7-specific feature, Cocoa Autolayout, on 10.6, which doesn't understand it. If you wish to support running on 10.6, you need to avoid using such features. You should be able to set the deployment target on the NIB, which will then cause warnings to show up for features which aren't supported by that deployment target.
Also, if you haven't already done so, you need to do something similar for your target's build settings. Set the deployment target. Unfortunately, that won't necessarily cause warnings for code which uses features that were introduced in 10.7. You can set up an alternative build configuration which builds against the 10.6 SDK and compile against that to learn where you're using post-10.6 features. See Apple's SDK Compatibility Guide for more info.
I'm building an application that takes advantage of Mac OS X 10.6-only technologies, but without giving up backwards compatibility to 10.5 Leopard.
The way I do this is by setting the 10.6 SDK as the base SDK, weak-linking all frameworks and setting the deployment target to 10.5 as described in:
http://developer.apple.com/mac/library/DOCUMENTATION/MacOSX/Conceptual/BPFrameworks/Concepts/WeakLinking.html
This works fine; before making a call that is Snow Leopard-only I need to check that the selector or indeed the class actually exist. Or I can just check the OS version before making the call.
The problem is that this is incredibly fragile. If I make a single call that is 10.6 only I blow Leopard-compatibility. So using even the normal code code completion feature can be dangerous.
My question: is there any way of checking which calls are not defined on 10.5 before doing a release build? Some kind of static analysis, or even just a trick (a target set the other SDK?) would do.
I obviously should test on a Leopard machine before releasing anything, but even so I can't possibly go through all paths of the program before every release.
Any advice would be appreciated.
Best regards,
Frank
You could change the target SDK to 10.5. The compiler will then output warning: definition for '-snowLeopardOnlyMethod:' not found messages.
I've been building a basic Cocoa application with Core Data and Interface Builder, and no extra coding, frameworks, or header files. I sent it to someone to test on their machine (a last-gen G5 iMac), and they got a message saying that their machine couldn't run it. I discovered the switch to compile for PPC, so I built a PPC version of the application to try out, and that produced the following error message:
You cannot use this version of Application on this version of Mac OS X.
I'm running Xcode 3.2.1, Interface Builder 3.2.1, and OS 10.6.2. The conversation with my tester was a bit confusing; at first it sounded like she only had Tiger on her machine, saying Leopard was incompatible (I corrected and said that Leopard should be, it's Snow Leopard that isn't), and then by the end of the conversation she was about certain that her machine was running Leopard, but had already shut it off by then. So I'm not sure which version of OS X is on the offending iMac, but it's the latest version of either 10.4.11 or 10.5.8 (the tester is in a remote location, so I can't verify personally at the moment).
What can I tweak to try and improve compatibility on my tester's machine?
If they're seeing that message, it's most likely because your app has the LSMinimumSystemVersion key (Minimum system version) set in the Info.plist. You should take this key out or set it to the actual the minimum OS X version you support.
Once you do this, you may well run into the next problem. (Probably a dynamic linker error as a result of using a framework or API that didn't yet exist on 10.4 or 10.5.)
The main problem here is that you're sending it out to a system where you haven't actually tried it. If you plan to support 10.4, 10.5, or both, I highly recommend that you find a spare hard drive, partition it up, and install 10.4.11 and 10.5.8. There are many issues that will crop up on older OS's and if you haven't tried it yourself, it's unlikely it will work smoothly on the first try.