Re: @loader_path and @executable_path
Re: @loader_path and @executable_path
- Subject: Re: @loader_path and @executable_path
- From: Joseph Crawford <email@hidden>
- Date: Mon, 12 Jan 2009 19:03:06 -0500
from what i have read @rpath is 10.5 ONLY
On Jan 12, 2009, at 6:47 PM, Cathy Shive wrote:
Hi Brandon,
I recently struggled with this issue (with not too much Xcode/gcc
experience) and I found that the @rpath gives very flexible results.
In the framework project, I set the 'Installation Directory' build
setting for the frarmework's target to @rpath.
Any project that links the framework to one of its targets has to
define for itself where it's going to look for it. To do this, the
target that is using the framework has to have its 'Runpath Search
Paths' defined in its build settings. So, if I'm going to embed my
framework in an application's executable I'd use something like
'@executable_path/../Framework' for the application target's
'Runpath Search Paths' build setting.
This is a great thing for frameworks that might be embedded in a
bundle like an IB Plugin that you want users to be able to click on
in the Finder (IB will be able to find the framework), or be
embedded in an app's executable. Each of these uses has different
needs and @rpath allows for that without adding a script to a build
phase to change the paths dynamically.
The downside is that users of your framework will have to do one
extra step when they are importing your framework into their
application projects - they have to set the 'Runpath Search Path'
setting to their app's target to @exectuable_path/../Frameworks or
@loader_path/../Frameworks (I don't think it makes a difference in
this case). It's not as user friendly, I guess.
I really don't know too much about this stuff either, I'm sure
someone else can explain it better - but this is the only thing that
worked for my framework in every case.
Cheers,
Cathy
On Jan 13, 2009, at 12:05 AM, Joseph Crawford wrote:
Brandon,
I can tell you what needs to be changed but it is not the suggested
route.
Everyone is saying that using @loader_path is the way to go over
@executable_path, however that said
You change it in your target build settings for your framework.
Stated by the author of Sparkle
"Oh, yeah, I've seen people need @executable_path. You would change
that in Install Path in the Sparkle target of Sparkle.xcodeproj."
But as I said people have suggested against that.
Dave Dribin - "In general, @loader_path is preferred over
@executable_path, as it allows embedded frameworks to work in both
an executable and a bundle, plugin, or sub-framework. The only
downside is that @loader_path requires 10.4 or newer. If you're on
10.5 or newer, @rpath is even better than @loader_path."
Joseph Crawford
On Jan 12, 2009, at 5:58 PM, Brandon Walkin wrote:
On 12-Jan-09, at 5:00 PM, Dave Dribin wrote:
On Jan 12, 2009, at 10:47 AM, Joseph Crawford wrote:
I do not know if this is a cocoa question or not, it is an error
I get when I hit build & go
This GDB was configured as "i386-apple-darwin".tty /dev/ttys001
warning: Unable to read symbols for "@loader_path/../Frameworks/
BWToolkitFramework.framework/Versions/A/
BWToolkitFramework" (file not found).
warning: Unable to read symbols from "BWToolkitFramework" (not
yet mapped into memory).
warning: Unable to read symbols for "@loader_path/../Frameworks/
Sparkle.framework/Versions/A/Sparkle" (file not found).
warning: Unable to read symbols from "Sparkle" (not yet mapped
into memory).
These are just debugger errors. This is most like due to those
frameworks being compiled in Release mode with their debug
symbols stripped. It should not affect debugging of your own
application.
I did some googling and found that people used a tool to use
@executable_path rather than @loader_path but I also read that
those values should be the exact same so changing them is not
the optimal change to make.
For an application, they resolve to the same thing.
Does anyone have any idea where I can see / set these values? I
have checked my Xcode Project Build settings, the framework
build settings, etc. and cannot find them.
They are set in the frameworks project, not yours. So if you're
linking to pre-built versions of Sparkle and BWToolkit, there are
no settings in your app that affect this.
In general, @loader_path is preferred over @executable_path, as
it allows embedded frameworks to work in both an executable and a
bundle, plugin, or sub-framework. The only downside is that
@loader_path requires 10.4 or newer. If you're on 10.5 or newer,
@rpath is even better than @loader_path.
-Dave
I'm the developer of BWToolkit. Some users have run into this
problem where the framework would work fine for them for a while,
and then one day it would output the warnings that Joseph
mentioned. My Xcode/gcc knowledge is a bit lacking, so I haven't
been able to figure this one out. Do you know what changes have to
be made in the BWToolkit Xcode project to fix this issue?
Thanks,
Brandon
_______________________________________________
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:
@gmail.com
This email sent to email@hidden
_______________________________________________
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
_______________________________________________
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