Re: Simple question on locating dynamic libraries at runtime
Re: Simple question on locating dynamic libraries at runtime
- Subject: Re: Simple question on locating dynamic libraries at runtime
- From: Ken Thomases <email@hidden>
- Date: Wed, 4 Aug 2010 14:53:48 -0500
On Aug 4, 2010, at 2:25 PM, Chris Goedde wrote:
> I'm adapting an existing Cocoa project to interface with Matlab, which requires linking to a dynamic library supplied by The Mathworks. I have it all set up so that compiling and linking works, but I can't figure out how to tell Xcode how to tell my app where to look for the dynamic library at run time. The library itself [libeng.dylib] lives in /Applications/MATLAB_R2009a.app/bin/maci, and I've created a sym link to this folder at /usr/local/matlab/bin.
Is your app intended to be used anywhere but on your own machine?
If not, then you can use hacks to get it find things where they happen to be on your machine. If you need it to work on other machines, you're going to have to do some more complicated stuff.
As for the hack, you can use install_name_tool to change the reference in your app to the library to refer to its full path. Alternatively, since the reference is apparently "@loader_path/libeng.dylib" at the moment, a real hack would be to add symlink in your app inside Contents/MacOS pointing to libeng.dylib.
You can use run-script build phases to perform these tasks as part of your build.
The way it normally works: each library has an "install name" baked into it by the linker. When you link something to that library, a reference to the library is baked into it -- but the reference does not use the path at which the library was found at link time, it uses the install name of the library.
Then, at load time, the dynamic loader uses the reference to find the library. There are some ways to tell the dynamic loader about other places to look. Those are documented in the dyld man page <http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man1/dyld.1.html>. That's not normally the way this issue is solved, though.
A better solution is to either a) take care to make sure the library has an install name that actually corresponds to its load-time location before the link step, or b) change the reference to the library after linking using install_name_tool. One way or another, though, you need to make the reference correct for load time.
References can be absolute paths, if the library is guaranteed to be at that path at load time. Or, if the executable and library are going to move about together, as in an application bundle, the reference can be executable-relative with @executable_path. If there's a reference from one library to another, and those libraries will move together but not necessarily with the executable, then the reference can be loader-relative with @loader_path.
There are also rpath-relative references, which are documented here: http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/RunpathDependentLibraries.html
Regards,
Ken
_______________________________________________
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