Re: using a dylib in the appfile.app/Contents/Frameworks?
Re: using a dylib in the appfile.app/Contents/Frameworks?
- Subject: Re: using a dylib in the appfile.app/Contents/Frameworks?
- From: Chris Hanson <email@hidden>
- Date: Fri, 23 May 2008 16:13:55 -0700
On May 23, 2008, at 3:09 PM, Tae-Won Ha wrote:
When I build, the dylib file gets copied to
the Frameworks folder. However when I remove the original dylib file
from $HOME/lib, where it was as I built, the app just crashes. If I
move the dylib file back to $HOME/lib, it works again. What should I
do to force the app to use the dylib file in the
appfile.app/Contents/Frameworks?
Every library, bundle and executable on Mac OS X has an embedded
"Install Name" that represents the full path at which it expects to be
installed.
When an executable links against a library, it copies the library's
Install Name into the linking executable, and at runtime the dynamic
loader (dyld) tries to load the library first from that location, and
then from a small set of fallback locations. These are documented in
the dyld(1) man page, just look for the
DYLD_FALLBACK_{FRAMEWORK,LIBRARY}_PATH environment variables:
dyld(1)
http://developer.apple.com/documentation/Darwin/Reference/ManPages/man1/dyld.1.html
You can change a library's Install Name using install_name_tool, or
you can specify it when the library is linked using the appropriate
build settings within Xcode.
There are also some special tokens that dyld supports, which it will
expand:
@executable_path: Expands to the path of the currently-running
executable.
@loader_path: Expands to whatever is attempting to load the
library.
@rpath: Tells dyld to search a set of paths supplied at
link time for the library.
For example, if you have a framework or library that you want to embed
in an application bundle's Frameworks directory, the Install Name
within the framework or library itself needs to start with
"@executable_path/../Frameworks" (since @executable_path is the path
to the application executable itself in the MacOS directory,
@executable_path/.. refers to the Contents directory).
Similarly, if you have a suite of applications that you want to have
share a set of frameworks, they should live in a directory structure
like this and have the following Install Names:
MySuite/
Foo.app
Bar.app
Frameworks/
MySuiteCore.framework - Install Name: @rpath/
MySuiteCore.framework/Versions/A/MySuiteCore
MySuiteKit.framework - Install Name: @rpath/
MySuiteKit.framework/Versions/A/MySuiteKit
Then each application should have its "runtime search paths" specified
(in the linking options in Xcode) as "@executable_path/../../../
Frameworks" which will cause dyld to search the shared Frameworks
folder for any libraries or frameworks whose Install Name starts with
the token @rpath.
-- Chris
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden