Re: linking problem
Re: linking problem
- Subject: Re: linking problem
- From: Chris Hanson <email@hidden>
- Date: Wed, 4 Jul 2007 17:27:43 -0700
On Jul 4, 2007, at 4:32 PM, mark wrote:
(2) Link your plug-in directly against the application rather than
against a stub library, by specifying the application as the Bundle
Loader in your plug-in's target build settings. (Keep in mind that
you'll need to pass the path to the actual application executable
as the Bundle Loader, not just the path to the .app wrapper.)
Quick documentation is available directly in the build settings
inspector within Xcode, in Xcode 2.1 or later; you can also check
the ld(1) man page section on its -bundle_loader flag for more
details.
I was hoping I wouldn't have to do that.
It means I have to hard-code the application location into the plugin.
If the app moves, the plugin will break.
Ah, but that *won't* be the case. Bundle Loader is special; what it
means is "treat this executable as a library at link time, but try to
find any symbols found in it *in whatever loads me* at run time."
So it doesn't matter if the application moves. The plug-in will look
for imports that originally came from the Bundle Loader at build time
in whatever executable loads it at run time.
How does apple pull it off with it's 10.X.Y SDKs?
When an app loads, globals will link to the running system, not the
SDKs.
The path where a library is located isn't what gets copied into
something that links the library. Rather, it's the "install path"
string that's embedded in the library that gets copied. So even
though a library or framework might be in an SDK directory, its
install path is set as if it were the real system.
-- 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