Re: dylib inter-dependencies, install_name_tool and @loader_path
site_archiver@lists.apple.com Delivered-To: installer-dev@lists.apple.com Importance: Normal User-agent: SquirrelMail/1.4.9a Hi again, Indeed, one of the problems was caused by a dynamically dylib loaded at run time (a plugin). The plugin was searched in a global system scope, instead of being searched inside my distribution. Hence, as far as checked, using @loader_path/**relative_path_to_B** inside a .dylib A to refer to a dependent library B behave as following: 1- if path_of_A/**relative_path_to_B** is existing dylib B is, this version of B is loaded 2- if path_of_A/**relative_path_to_B** is NOT can existing dylib B, then B is searched in the global system path. Is this correct? Anyhow, my first question is still valid:
install_name_tool allows changing the "id" of a dynamic library, with -id. But What Does "id" Mean ? And what is the impact of the lib's "id" on loading? I've browsed the doc and the Net for long, but did not find any clear info...
Thanks, Nicolas
Hi folks,
I am trying to make my applications distribution for mac OSX.4 and X.5, but have a couple of problem with the dynamic loading of libraries.
My first question is: install_name_tool allows changing the "id" of a dynamic library, with -id. But What Does "id" Mean ? And what is the impact of the lib's "id" on loading? I've browsed the doc and the Net for long, but did not find any clear info...
My second question is: What does @loader_path means exactly ? I did not find any clear info on this, and basically, the observed behavior does not match what the doc (apparently) says.
Let's now get into a bit more details.
My distribution contains various executables, both bundled apps and command-line, that rely on various interdependent libraries. The distrib looks like: distrib |_ bin |_ cmdlineexecutable |_ application.app |_ lib |_ A.framework |_ B.framework where both executable depend on A AND B, and where A depends on B.
Since the executables are NOT on the same level in the distribution tree, using @executable_path inside a library to refer to another library is NOT possible.
I guess I have to use @loader_path: the executable would refer to a libraries using @executable_path, and the libraries would refer to each others using @loader_path
According to the doc:
Library-relative location. To specify a file path relative to the location of the library itself, place the @loader_path macro at the beginning of the pathname.
However, when using @loader_path, and when the framework is installed BOTH inside my distribution AND in a system-searchable location (eg: /Library/Framework) then BOTH versions of a library are loaded when launching the app.
I guess that: - the executable, that depends on frameworks A and B refered by using @executable_path, loads the executable-relative versions of the frameworks A and B - framework A, that depends on framework B referred by using @loader_path, loads the version of B which is located in /Library/Frameworks
Hence, @loader_path would NOT refer to the currently-loaded library path... And the doc would lie :/
I would appreciate any help on this situation.
Thanks much for your attention, best- Nicolas
PS: First message on this list. I hope it I picked the correct list. Sorry if I was wrong :/
_______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.a... This email sent to site_archiver@lists.apple.com
participants (1)
-
Nicolas.Castagne@imag.fr