Re: App works in debugger, won't launch in Finder
Re: App works in debugger, won't launch in Finder
- Subject: Re: App works in debugger, won't launch in Finder
- From: Rick Mann <email@hidden>
- Date: Sat, 2 Oct 2010 01:57:33 -0700
Thanks, Ken. Turns out, it was partly that, but the real problem was the differing working directories, depending on whence the app was launched.
I did find a resource that told me about @executable_path, so I fixed up that aspect as well.
I do have another question. I will ship my app with a number of built-in plug-ins, but I also want the user to install additional plug-ins, or even write their own. Those plug-ins need to find my app's Framework, both for building and execution. How do I handle that?
Does the Framework need to be pulled out of the .app and put somewhere more global? That would require an installer, which I'd like to avoid, if at all possible.
TIA,
--
Rick
On Oct 2, 2010, at 01:53:31, Ken Thomases wrote:
> On Oct 1, 2010, at 11:52 PM, Rick Mann wrote:
>
>> I have an app that has a framework internally (and some plug-ins). When I launch it from Xcode (debugging), everything works fine. But if I launch it by double-clicking the icon in the Finder, I get the crash dialog with "Library not loaded: foo", where foo is the internal framework.
>>
>> The path to the library it can't load isn't the one inside the .app package, but rather it's trying to load it from ~/Library:
>>
>> Library not loaded: /Users/rmann/Library/Frameworks/TelemetryPlugInFramework.framework/Versions/A/TelemetryPlugInFramework
>> Referenced from: /Users/rmann/Projects/Mac/Telemetry/depot/trunk/build/Debug/Telemetry.app/Contents/MacOS/Telemetry
>>
>> I figure I've failed to set some library search path somewhere, but I'm not sure what it is I'm missing.
>
> What does the following command show?
>
> otool -L /Users/rmann/Projects/Mac/Telemetry/depot/trunk/build/Debug/Telemetry.app/Contents/MacOS/Telemetry
>
> Basically, your app has a reference to each library and framework it is linked against. That reference is a path. For references to system libraries and frameworks, it is typically an absolute path. For references to custom libraries and frameworks that are intended to be part of your application bundle, it is typically a path starting with @executable_path, @loader_path, or @rpath. However, you may have unintentionally created a reference with a relative path (possibly just a name with no directories) or an absolute path to where the library or framework is located at build time. Neither of those is useful.
>
> The dyld(1) man page explains how the library or framework is found at load time. In particular, there are some default fallback search paths used if it's not found where it's referenced.
>
> Launching may be working when launched from Xcode due to the working directory. Xcode may launch your app with a different working directory than the Finder does. This may affect how relative paths are resolved. I suppose it's also possibly that Xcode is setting some DYLD_* environment variable(s) that affect how the framework is located.
>
> To get the reference from your executable to your framework correct, you have two basic choices: 1) make sure the framework is built with an install name that is the reference your executable should use to find it, or 2) fix up the reference after the executable is linked to the framework using install_name_tool. Number 1 can be accomplished with the LD_DYLIB_INSTALL_NAME (Dynamic Library Install Name) build setting for the framework target. Number 2 can be accomplished with a run-script build phase in the app target, positioned after the Link Binary With Libraries phase.
>
> Regards,
> Ken
>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden