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 (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
