Hi Joseph,
This thread has gotten a little mixed up ;) I was replying to
Brandon's reply about your problem. So, in order for what I suggested
to work, he would have to first release the framework with those
changes to his framework's build setting. But that's totally
something he would want to research and test on his own to be sure
that he prefers that setting.
Sorry if that was confusing!
Best,
Cathy
On Jan 13, 2009, at 1:06 AM, Joseph Crawford wrote:
Cathy,
I tried adding @loader_path/../Frameworks/ and @executable_path/../
Frameworks/ to my projects Runpath Search Paths and I still get the
errors shown.
Joseph Crawford
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 (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/codebowl%40gmail.com
This email sent to codeb...@gmail.com
_______________________________________________
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/catshive
%40gmail.com
This email sent to catsh...@gmail.com
_______________________________________________
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/catshive%40gmail.com
This email sent to catsh...@gmail.com
_______________________________________________
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
