site_archiver@lists.apple.com Delivered-To: installer-dev@lists.apple.com Thread-index: Acke84l+EibmL8XiRLOqObVwNucjRwAYI0Bw Thread-topic: dylib inter-dependencies, install_name_tool and @loader_path Hey Nicolas, Yup, should work--evfen with your dylibs in a relative location, as long as you remember to change the dependency path in the things that need it to the same path. It should expand it properly at runtime, no matter where your user relocates your app. Only way to for sure know is to test it on your app :) In this case one you change everything and package it up to distribute, it will work the same. I do think there is slightly different linking options in leopard then were in tiger, at least through the xcode linker bits, so if you are hooking this up in xcode be sure to do some reading. But just using install_name_tool to change things, at least in my experience it just works-- I haven't had any bugs assigned back to me that trace back to a linking problem that I have fixed on an app for OS X. Lisa -----Original Message----- From: installer-dev-bounces+lisaweimer=smarttech.com@lists.apple.com [mailto:installer-dev-bounces+lisaweimer=smarttech.com@lists.apple.com] On Behalf Of Nicolas.Castagne@imag.fr Sent: Thursday, September 25, 2008 3:33 AM To: installer-dev@lists.apple.com Subject: RE: dylib inter-dependencies, install_name_tool and @loader_path Hi Lisa,
I don't know if this will help at all, but hopefully it doesn't cause more confusion for you. Less confusion, and great help indeed :/ Thanks for your answer.
Everything seems OK now. Indeed, the problem was caused by a dylib loaded at run time : my executable search path loaded the system-scope library. One question remains...
id in install name tool allows you to change the install_name. You can read more about install_name in the ld man page. You can set the install_name in the Xcode linker options, or you can use install_name_tool to change this setting. Install_name (id) is means this: things linked against that library will record that path as the way dyld should locate that library.
Well, since my dylibs are in a relative location, I've used for them the id: @loader_path/MyDyLib.dylib Would you think that's OK? Will @loader_path be taken into account, and changed to the actual absolute path of the loaded library? As far as I checked, that's OK. But... Who knows... Best- Nicolas
Hi Nicolas,
I've just finished remapping a bunch of frameworks and dylibs for my company's applications, so I will take a crack at answering this.
It sounds like your dylib was not relocated properly if it loaded the global one first. If you properly relocate things, then the system will always use your copy of whatever was relocated.
I don't know what happens if the copy you want to use doesn't exist--that is, I can't confirm that it searches the global system path after trying your path, but based on my linux experience, it wouldn't surprise me if that was the default behaviour. (I think if you want it to search a specific series of paths, you need to set this behaviour in xcode at linking time using -rpath. I don't know much about doing things in xcode at linking time so I can't help you there.)
id in install name tool allows you to change the install_name. You can read more about install_name in the ld man page. You can set the install_name in the Xcode linker options, or you can use install_name_tool to change this setting. Install_name (id) is means this: things linked against that library will record that path as the way dyld should locate that library.
@loader_path, as far as I understand it means this: at run time dyld replaces @loader_path with the path to the Mach-O binary that loaded it (an executable or another shared library of some sort). Unlike @executable_path which only refers to the main executable.
When you changed the ids and references did you use this procedure? Use install name tool 1. change the id of a.framework (no longer is the system copy) 2. change the id of b.framework (no longer is the system copy) 3. in a.framework, change the reference to look for your copy of b.framework (Install_name_tool -change) 4. in your exececutable change the references to look for your copies of a.framework and b.framework. (Install_name_tool -change)
You can check all of your work with otool -L, see where and how things are referring to each other.
So for your app and libs, the first thing I would do is run otool against them all, and verify that things are referring to the right things, and also verify the places they are looking actually exist.
I've read before that install_name_tool only works if the new install_name (id) is no longer than the old one. But I've never run into this limitation yet, lucky me.
I don't know if this will help at all, but hopefully it doesn't cause more confusion for you. Other mail lists that might help are xcode development mail lists.
Best, Lisa Weimer
-----Original Message----- From: installer-dev-bounces+lisaweimer=smarttech.com@lists.apple.com
[mailto:installer-dev-bounces+lisaweimer=smarttech.com@lists.apple.com]
On Behalf Of Nicolas.Castagne@imag.fr Sent: Wednesday, September 24, 2008 7:44 AM To: installer-dev@lists.apple.com Subject: Re: dylib inter-dependencies, install_name_tool and @loader_path
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/lisaweimer%40smartt
ech.com
This email sent to lisaweimer@smarttech.com
_______________________________________________ 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/nicolas.castagne%40 imag.fr
This email sent to nicolas.castagne@imag.fr
_______________________________________________ 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/lisaweimer%40smartt ech.com This email sent to lisaweimer@smarttech.com _______________________________________________ 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