Re: dyld issues with library not in standard location
Re: dyld issues with library not in standard location
- Subject: Re: dyld issues with library not in standard location
- From: "Peter O'Gorman" <email@hidden>
- Date: Fri, 21 Oct 2005 21:47:17 +0900
Stefan Werner wrote:
In that case, skip example, repeat question: What are the benefits of
having the library path encoded in the dylib file? My Xcode projects have
this additional build phase with install_name_tool that they would not
have in other environments. I'm sure there must be a reason why the
designers of MachO included it, but from my past experience on other
platforms I can't come up with any idea. What is the secret?
The loader needs to know where to find the needed shared libraries. On some
systems it searches some default paths, a couple of application relative
paths and the current working directory, so on those systems there are
severe restrictions on where a library can go. On other systems, a library
can go anywhere at all, but the loader still needs to find it, so the
library's clients encode this information, then when the loader loads the
client library or application, it can figure out where to look. All unix
systems that I'm aware of do this, using -rpath -R -blibpath etc etc.
To be honest, I think you might consider filing an enhancement request for
the xcode IDE. If you have a project that builds a framework or library and
builds a bundled application which will contain that framework or library,
it probably should be able to figure out the -install_name flags for you.
Peter
_______________________________________________
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