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/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
