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: "Tae-Won Ha" <email@hidden>
- Date: Sat, 24 May 2008 21:32:23 +0200
Thanks for the help! Got it solved with install_name_tool and otool. Tae
On Sat, May 24, 2008 at 1:13 AM, Chris Hanson <email@hidden> wrote:
> 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
>
--
http://www.th.physik.uni-bonn.de/people/tha/
_______________________________________________
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