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: Thu, 5 Aug 2010 11:06:01 -0500
On Aug 5, 2010, at 8:09 AM, Chris Goedde wrote:
> This app is meant to be used primarily by me (or perhaps students working for me), on my own machine(s). After thinking about the pros and cons of various solutions, I decided to have Xcode copy the dynamic library into my app's bundle. The snag with that is that libeng.dylib is only the tip of the iceberg; it depends on some as yet unknown number of libraries (at least 9, but there are 155 *.dylib files in that folder ...).
>
> My current solution is to just use ~/.MacOS/environment.plist to set DYLD_LIBRARY_PATH to /usr/local/matlab/bin. But if I want to pursue a solution in Xcode, I have a couple questions.
>
> (1) What's the best way to suss out all the dependencies between the dynamics libraries? I was using otool -L, but libA -> libB -> libC, etc, so it's tedious. Is there a better way?
>
> (2) Once I identify all the required libraries, what's the best, most future-proof, most maintainable way to copy them into my app's bundle? (Note that some of the dependencies are actually sym links, e.g. libeng.dylib is linked to libicudata.dylib.38, which is actually a sym link to the file libicudata.dylib.38.1.)
>
> (3) Something else? (I'm hesitant to play around with install_name_tool because of the maze of dependencies in the libraries.)
From your original post, I seem to recall that the install name of libeng.dylib was already @loader_path-based. I'm guessing the rest of Matlab's libraries were built the same way. You can verify using otool -L.
So, if you just copy the lot of them into your app bundle in the same relative structure, then they'll all find each other. Then you only have to take care of the references from your app's executable to its immediate dependencies, which you can adjust using install_name_tool after the link step. You'd make those references relative to any of @executable_path, @loader_path, or @rpath. For references from the executable, @executable_path and @loader_path are functionally equivalent.
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